From: Eric Mahurin <eric_mahurin@...>
Date: 2005-10-20T11:13:09+09:00
Subject: Re: Method annotation and anonymous functions

--- "David A. Black" <dblack@wobblini.net> wrote:

> Hi --
> 
> On Thu, 20 Oct 2005, Trans wrote:
> 
> >
> > Jeff Wood wrote:
> >> Yes it would, but I don't see another way to do
> attribution of methods
> >> without causing compatibility issues .... do you?
> >
> > Nitro/Facets annotations system works like so:
> >
> >  class X
> >    def foo ; "foo" ; end
> >    ann :foo, :returns => String
> >  end
> >
> >  X.ann :foo, :log => true
> >
> >  X.ann.foo.returns  #=> String
> 
> Ugh, if I may permit myself the expression  That means
> goodbye to
> things like:
> 
>    def meth(thing)
>      thing[some_thing_else]
>    end
> 
> Pinning down the class of return values is similar to pinning
> down the
> class of arguments -- arguably even more
> duck-typing-unfriendly, since
> you're specifying not only what a given object has to be but,
> potentially, what *its* methods have to return.

I'll be the devil's advocate...  A good use of something like
this would be if we had a VM that had type inference (like the
self VM).  Where it had trouble inferring the type (pretty much
a class - to get the exact methods at compile time), giving the
class of the args and return value would help it.

But of course the best solution is to improve the type
inference engine (if we had one).  Ruby is a dynamically typed
language and I think it should stay that way.  Let the VM guys
continually do optimizations instead of dirting the language
with static-type hints.  I'd be afraid of too many people
abusing it and disabling the power and beauty of duck-typing.




		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/