Asp Forum - Matz' Wild Ideas: Annotations

Trans

8/26/2006 8:01:00 PM

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.

T.

[1] http://www.rubyist.net/~matz/slides/rc2005/...

6 Answers

Matt Todd

8/27/2006 6:22:00 AM

> 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.

M.T.

Trans

8/27/2006 7:53:00 AM

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

David Vallner

8/27/2006 10:05:00 AM

Matt Todd wrote:
> 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.

To add some more confusion, I would have thought first-class annotations
as something to be processed (also) before runtime - though probably
causing at worst warnings by default to get the dynamicity reduction
threat out of the way.

I can't yet decide if I'd like features implementable with both
annotations and already existing metaprogramming facilities in one or
the other. There's the efficiency demon on the left shoulder, and the
metaprogramming imp on the right...

David Vallner

Matt Todd

8/27/2006 6:09:00 PM

class X
def foo arg1
# do stuff here
end
annotate :foo do
requires "arg1 >= 10" # or whatever it takes
overriding true
visibility public # though I think what we've now works well
end
end

I like your last try, Trans, but it just doesn't sit too well with me.
This example above is about as verbose as I'd like it... #annotate
being a class method that actively annotates the methods properties.
This way _could_ be easier to implement, and less destructive of the
current syntax. (I like that.) Plus, it's a method, so it doesn't
matter where or when you call it.

Also, I don't think we should duplicate visibilitiy... there's a
reason we have what we already have for defining public and private
and protected.

One of my biggest concerns/thoughts, really, is how to preserve the
test "arg1 >= 10" to be both reprintable and testable. I mean, I guess
it could be done with some hacking to get the binding of the method
and then #eval it with that binding, but still, you're passing a
string as a test.

I understand and agree with you, Francis: annotations open up quite a
bit. In fact, it's a step towards good AOP (Aspect Oriented
Programming). (Or am I thinking of another term... crap, where's my
PragProg book!?) But, on configuration vs. convention, it would be
perfectly sufficient to have a conventional annotation, and from
there, anything specific just overrides it. That way we don't have to
worry about breakage and for those that are perfectly happy with the
way things are now (a good majority of the people) can go on their
merry way. Is there any other way!? :)

Cheers,

M.T.

Pau Garcia i Quiles

8/27/2006 7:10:00 PM

On Sunday 27 August 2006 05:11, Trans 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.
>
> T.
>
> [1] http://www.rubyist.net/~matz/slides/rc2005/...

It would be really nice to implement something like Spark's annotations:
http://en.wikipedia.org/wiki/SPARK_programming_language#Annotatio...

--
Pau Garcia i Quiles
http://www.e...
(Due to the amount of work, I usually need 10 days to answer)

Trans

8/30/2006 4:16:00 PM

Matt Todd wrote:
> class X
> def foo arg1
> # do stuff here
> end
> annotate :foo do
> requires "arg1 >= 10" # or whatever it takes
> overriding true
> visibility public # though I think what we've now works well
> end
> end
>
> I like your last try, Trans, but it just doesn't sit too well with me.
> This example above is about as verbose as I'd like it... #annotate
> being a class method that actively annotates the methods properties.
> This way _could_ be easier to implement, and less destructive of the
> current syntax. (I like that.) Plus, it's a method, so it doesn't
> matter where or when you call it.
>
> Also, I don't think we should duplicate visibilitiy... there's a
> reason we have what we already have for defining public and private
> and protected.
>
> One of my biggest concerns/thoughts, really, is how to preserve the
> test "arg1 >= 10" to be both reprintable and testable. I mean, I guess
> it could be done with some hacking to get the binding of the method
> and then #eval it with that binding, but still, you're passing a
> string as a test.
>
> I understand and agree with you, Francis: annotations open up quite a
> bit. In fact, it's a step towards good AOP (Aspect Oriented
> Programming). (Or am I thinking of another term... crap, where's my
> PragProg book!?) But, on configuration vs. convention, it would be
> perfectly sufficient to have a conventional annotation, and from
> there, anything specific just overrides it. That way we don't have to
> worry about breakage and for those that are perfectly happy with the
> way things are now (a good majority of the people) can go on their
> merry way. Is there any other way!? :)

FYI. I'm working on this for next version of Facets' Annotations
system.

Thanks,
T.

comp.lang.ruby

Matz' Wild Ideas: Annotations

Trans

Matt Todd

Trans

David Vallner

Matt Todd

Pau Garcia i Quiles

Trans

x Login to ForumsZone