Seriously ....

It's not about the type stuff ... that was a bad example cause it set
everybody off ... and you're using it as a Red Herring ... "It sucks
because it's for return types! It breaks duck typing ! " .... It
doesn't change anything, it simply gives you information you can later
query about a method.

It's for whatever people want to say about the method ( like maybe a
warning that the function modifies it's object, or a documentation
string available during runtime? or whatever else, like maybe a flag
to say that a functions already been modified by some aspect-oriented
code or meta-programming hook or something, in case somebody makes a
cyclic reference... )

Matz surely wouldn't let people try  to get him to hardcode a list of
available attributes or something... and, there's no mandate that you
have to use them when they do exist.

This would be a useful thing. Why not let methods be objects too?

Anyways, please disregard the return annotation, it's simply a
meaningless example ( but that's something that should be confirmed by
the OP ).

j.

On 10/19/05, Eric Mahurin <eric_mahurin / yahoo.com> wrote:
> --- "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/
>
>


--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood