From: Robert Dober <robert.dober@...>
Date: 2006-04-02T16:02:38+09:00
Subject: Re: Typed Parameters

------=_Part_1262_6255271.1143961347441
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 4/2/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 =3D 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.
> >
> >
> >




I quite agree, showes my how helpless I braught this up. :-(
Should have named the thread "Easier ways to enforce contracts".
Is that not strange that we think types immediately and than are afraid of
ancient Computer Science History.

Now there is another point.

My programs often pass objects of an unexpected "contract, behavior, type,
mixin interface" you name it.
I would like a modern language to help me, the *stupid* programmer to be
more *effective*
Ruby claims that.

So let me suggest the following syntax

def foo (bar, foobar)  is a shortcut to
def foo( bar, foobar : Object) which is a shortcut to
def foo( bar, foobar : { |para| Object =3D=3D=3D para } )  so we can put an=
y
constraint in there.

I still think that is a good thing for readability and maintenance and
*nobody* would be forced to use it.
Furthermore we are not forced to use the block inside the formal parameter
list, it would just give us the opportunity.

I really fail to see why this is inhibiting the language.
Such programs fail explicitly and early, which is better (I claim) than
maybe failing later or just not behaving as expected.

Robert



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


--
Deux choses sont infinies : l'univers et la b=EAtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

------=_Part_1262_6255271.1143961347441--