Matz' Wild Ideas: Annotations

[Trans]

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/index.html

 

[Matt Todd]

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]

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]

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]

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]

--nextPart4473612.Vdnv58jMtv
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I was looking at Matz' Wild and Weird ideas [1]. He talks about
annotations at one point and gives this example:

# @require: arg1 >=3D 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 >=3D 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/index.html

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

=2D-=20
Pau Garcia i Quiles
http://www.elpauer.org
(Due to the amount of work, I usually need 10 days to answer)

--nextPart4473612.Vdnv58jMtv
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBE8e3o/DzYv9iGJzsRAhftAJ4rWqk5rULSs9Lc/HCaaYik1D+O7gCgvkXw
NtSpMrFnoseZE9L4XKdQjfw=
=XBx3
-----END PGP SIGNATURE-----

--nextPart4473612.Vdnv58jMtv--

 

[Trans]

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.