From: Trans <transfire@...>
Date: 2006-08-27T16:55:09+09:00
Subject: Re: Matz' Wild Ideas: Annotations


Matt Todd wrote:
> > I was looking at Matz' Wild and Weird ideas [1]. He talks about
> > annotations at one point and gives this example:
> >
> >   # @require: arg1 >= 10
> >   # @overriding: true
> >   # @visibility: public
> >   def foo(arg1)
> >     ...
> >   end
> >
> > I'm not too keen on using comments like this. It separates the
> > annotations from ordinary code, thwarting  the great dynamic nature of
> > Ruby. Perhaps autovivify class level methods with a syntax like call
> > instance vars could be used instead:
> >
> >   @foo require: lambda { arg1 >= 10 }
> >        overriding: true,
> >        visibility: public
> >
> > That way they could be used any where, even encapsulated and reused.
>
> module Annotate
> private
>   def validate test
>     raise "Requirement failed" if test == false
>   end
> end
>
> class X
>   include Annotate
>
>   def foo arg1
>     validate arg1 >= 10
>     overriding true
>
>     # do stuff here
>   end
> end
>
> Of course, this only works as far as what we can actually do with the
> complexitiy of methods. I'm not really sure what's intended for
> 'overriding' because it's a little ambiguous (to me, at least). But
> 'validate' works.
>
> I guess I should go read up on what Matz said to get a better understanding.

To be annotations though, they really need to be accessible and
redefinable. This was also an issue with the commented form. Also it
woul dbe nice if they were reusable, so you could defeine and
annotation prior to the acual method existing. It occurs to me though
that the name could be omitted if it goes to the proceeding method
definition:

   @( require: lambda { arg1 >= 10 },
         overriding: true,
         visibility: public )
   def foo arg1
     ...
   end

Granted, yours look nicer though :) Hmm... maybe:

  ann foo 
    arg1 > 10
    overriding
    visibility public
  end