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

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