From: Daniel Nugent <nugend@...>
Date: 2006-04-02T10:21:35+09:00
Subject: Re: Typed Parameters

Maybe the code for that could look something like this:

def foo(arg1, arg2)
  BLAHBLAHBLAH STUFF GOES HERE
end.pre do |*args|
  SOME MORE STUFF
end.post do |*result|
  A LITTLE MORE
end.around do|*args, &method|
  SOME
  method.call(transformed_args)
  STUFF
end

And then you could dynamically add and remove the pre and post
conditions or whatever.

On 4/1/06, Daniel Nugent <nugend@gmail.com> wrote:
> Actually... now that I'm looking about it, that's kinda dumb, we might
> as well just add pre, post, and around calls so we can more cleanly
> seperate the Type and condition checks from the actual method.
>
> On 4/1/06, Daniel Nugent <nugend@gmail.com> wrote:
> > Well, I think you should allowed to put a selective effect on the
> > remaining arguments, but it should at least allow you to be a little
> > smarter than simply checking one single Type.  I'd like to see you
> > able to check against multiple types as well as methods and
> > combinations thereof, like
> >
> > def foo(arg1 : (Array and :custom_array_method) or Hash or :special_method)
> >
> > Then at least it's simply a syntactic convenience for writing
> > respond_to? and kind_of? calls.  And, logically, you should be able to
> > assign these parameter checks to a variabe so you can reduce the
> > duplication of them, although I don't have a clue as to what a good
> > syntax for that would be... Maybe something like:
> >
> > type_check = TypeCheck.new do |var|
> >   case var
> >   when Array
> >     return true if var.respond_to? :custom_array_method
> >   when Hash
> >     return Hash
> >   else
> >     return true if var.respond_to? :special_method
> >   end
> >   return false
> > end
> >
> > And, of course, you can do any checking you want in the block. You
> > could then do this:
> >
> > def foo(arg1 : type_check)
> > def bar(arg1, arg2 : type_check)
> >
> > On 4/1/06, Trans <transfire@gmail.com> wrote:
> > > <blockquote>
> > > It's not actually that practical, and such things end up making your
> > > code very much like C++ and Java.
> > >
> > > Ruby is smarter than that. Ruby can do more than that.
> > >
> > > Think in terms of what your object's required capabilities are instead
> > > of pretending that a class indicator is sufficient for that.
> > > </blockquote>
> > >
> > > While I understand you pointr Austin --obviously where talking Duck
> > > Typing here. But I think it is interesting to condier that this is some
> > > respect antithetical to OOP in general --I mean the reciever _is_ a
> > > specific type. And that reacieve detemine the functionality of the
> > > method call. It is sort of as if you were progamming in a more
> > > traditional functional language and _had_ to specifiy the type of the
> > > first argument, but never the remaining.
> > >
> > >   foofunc(  FooClass foo, clever, smart, stupid )
> > >
> > > instead of
> > >
> > >   foo.foofunc( clever, smart, stupid )
> > >
> > > So why shouldn't any of the other participating objects have a
> > > selective effect too?
> > >
> > > T.
> > >
> > >
> > >
> >
> >
> > --
> > -Dan Nugent
> >
> > Don't Feel Like Typing?  Send me a voicemail:
> > http://odeo.com/sendmeamessage/DanNugent
> >
>
>
> --
> -Dan Nugent
>
> Don't Feel Like Typing?  Send me a voicemail:
> http://odeo.com/sendmeamessage/DanNugent
>


--
-Dan Nugent

Don't Feel Like Typing?  Send me a voicemail:
http://odeo.com/sendmeamessage/DanNugent