Method annotation and anonymous functions

[Eric Mahurin]

Attributes don't do a whole lot of good unless there is a
standard set of them. And attributes that have to do with
static-typing (in a dynamically typed language) shouldn't be in
that set. If the attributes are completely arbitrary and have
no effect, then they should just be in the comments.

... the attributes have NOTHING to do with duck typing...
that was
simply an example chosen by somebody else.
=20
I would be using the attributes for testing ...

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20

 

[Jeff Wood]

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.

Hi --

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 =3D> String
end

X.ann :foo, :log =3D> true

X.ann.foo.returns #=3D> 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/

 

[itsme213]

To remedy I decided to
use Symbol instead since we typically use those to reference methods
(perhaps even better would be a sublclass MethodName < Symbol).

That would be the best solution. Specially if MethodName was aware of
namespaces, giving us a hook for selector namespaces!

 

[Trans]

Hi --

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.

Perhaps a bad example, b/c as Jeff said, it has no actual effect on
anything. Annotations are just notes. Nothing more. They only become
more when people use them to do particular stuff. For instance Og uses
them to determine how to map objects to a sql/database.

In fact I would like to add annotation namespaces. So that Og can
separate it's annotations from other's. But I'm not yet sure how that
will effect the interface.

T.

 

[Trans]

That would be the best solution. Specially if MethodName was aware of
namespaces, giving us a hook for selector namespaces!

Whoa! You may have just killed many a big bird with one ity bity hook!
You give me notions, but could you elborate more?

T.

 

[ES]

<snip intro>

Annotated functions:

class A
def foo(a, b)
.visibility rivate # how can this be parsed? (the above line
has no trailing marker to signal it as one expression
.returns Integer
begin
....
end

def foo2(a, b).visibility(private).returns(Integer) { ... }

f3 = def foo3(a,b)
end
f3.visibilityprivate).returns(Integer)

Oh please no! Annotations are, as can be inferred from the name, comments on the
code. Could we just keep these in the comment section? Then we will have a tool
which reads the documentation and can

1) Do RDoc-like external documentation
2) embed documentation in the code itself (in the objects or as separate data)
3) do both 1 and 2 at the same time
4) do nothing if the user wants to disable it.

<snip rest>

Steve Tuckner

E

 

[gwtmp01]

Oh please no! Annotations are, as can be inferred from the name,
comments on the
code. Could we just keep these in the comment section? Then we will
have a tool
which reads the documentation and can

1) Do RDoc-like external documentation
2) embed documentation in the code itself (in the objects or as
separate data)
3) do both 1 and 2 at the same time
4) do nothing if the user wants to disable it.

A couple thoughts.

For annotations to be manipulated via tools there
has to be a stable/standard syntax. If the annotations appear
as Ruby comments then you'll have to invent some other parser to extract
information from the comments and the information won't be available at
runtime (no meta-programming based on annotations).

If the annotations are part of the Ruby syntax then the Ruby parser
and meta-programming tools can come into play.

In order to be useful across classes/gems/packages/authors there
needs to
be some standard semantics associated with the annotations. Otherwise
different authors will choose different meanings for the annotation
names/identifiers.
This is true for annotations done in comments or as part of an extended
Ruby syntax.


Gary Wright

 

[David A. Black]

Hi --

It's really a VERY cool idea. I really hope it makes it in. I know
most people seem to hate adding a little punctuation ... but sometimes
it can be a good thing.

The thing is, I've spent literally years watching literally dozens and
dozens of things being suggested, *all* of which involve new
punctuation and all of which someone thinks are good ideas. If even a
tenth of them were adopted, Ruby would be about 90% of the way to
being in the Perl bracket of punctuation intensity.

I know it sounds strange, but I actually consider the clean line of
Ruby a "feature" (albeit an optional one, as to its use which
counts for more than almost every RCR imaginable to me.


David

 

[Tim Hunter]

I know it sounds strange, but I actually consider the clean line of
Ruby a "feature" (albeit an optional one, as to its use which
counts for more than almost every RCR imaginable to me.

+1

 

[Christophe Grandsire]

+1

+100 (or is that not allowed to add so many points at once? )
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

 

[Bob Hutchison]

Hi --

What punctuation has to be added? I like the way it is done in the
example.

The thing is, I've spent literally years watching literally dozens and
dozens of things being suggested, *all* of which involve new
punctuation and all of which someone thinks are good ideas. If even a
tenth of them were adopted, Ruby would be about 90% of the way to
being in the Perl bracket of punctuation intensity.

I know it sounds strange, but I actually consider the clean line of
Ruby a "feature" (albeit an optional one, as to its use which
counts for more than almost every RCR imaginable to me.

I agree about the syntax. The example that Tran provided doesn't
require new syntax, it works, and it does something that I think is
*very* useful. I'll reproduce his example here:

This is simple and so unexpected, to me at least, that it seems
brilliant (forget the :returns bit, it is irrelevant). I think I'm
still not used to what can be done with the mixing of compilation and
runtime in ruby.

I tried writing a toy implementation of this last night to see if
it'll solve a problem that I'm going to have to deal with soon. I'm
working on a system that automatically augments class definitions and
this is a great way for a programmer to provide additional hints and
fine-tuning control -- in fact, this opens up a lot of possibilities.
The implementation I came up with requires that include/extend trick
that Robert Klemme mentioned in the "class method aliasing" thread
the other day, but still. I'll soon cheat and look at what nitro and
facets did.

Cheers,
Bob

 

[Paul Brannan]

Aside from looking icky, how does doc() know what symbol to use to apply
the annotation with?

I realize now that I should have written:

private \
module_function \
doc "This is a docstring", \
def baz(a, b, c)
end

You are right that this is ugly (and it produces warnings). But it
avoids introducting a new syntax.

It's also possible to use Binding.of_caller and method_added to do
method annotations. Use of such a library would look like this:

private
module_function
doc "This is a docstring"
def baz(a, b, c)
end

Paul

 

[Paul Brannan]

I think I'm coming from a different perspective. I haven't seen any
examples of this that make me think it's worth either incompatibility
or new punctuation. I strongly dislike the idea of having a
specification of the class of the return value (object) of a method,
since that militates against duck typing. But maybe that's just an
example.

It's useful for documentation.

I like that ri Array#+ tells me that + returns an array. If ri told me
that it returned an object that supports the [] and []= operations, I
would possibly convert the return value to an array before using it.

IMO what a method expects from the user should be as minimal as
possible, to make the method as reuseable as possible, but what the user
can expect from a method (both what the method does and what it returns)
should be very precisely specified. If the type or meaning of the
return value of a method changes, there will often be an
incompatibility; such changes should be made with caution.

Paul

 

[Jeff Wood]

------=_Part_5377_16232210.1129824179155
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I agree with you that it is nice and clean, and to me punctuation, methods,
keywords ... all the same ...

so, yeah if somebody wants ann or attrib or whatever, that's fine ... but,
having to pass a symbol for the wrapping function is bogus. You are inside
the declaration of the function, that should be enough. ... There are
methods in Kernel to tell what method you are inside ... Use those inside
your attrb or whatever function so that people don't have to deal with that
...

It's just another source of confusion when somebody forgets to update a
symbol on their attributes.

anyways. I agree, I absolutely love ruby's syntax ... I wouldn't trade it
... and if there's a method that'll do the attributes cleanly, then I'm all
for it ... I don't *want* the punctuation, I just figured it was cleaner (
but cleaner doesn't mean clearer ) ... but, matz is *almost* always righ=
t
in his decisions ( all respect intended ).

j.

What punctuation has to be added? I like the way it is done in the
example.


I agree about the syntax. The example that Tran provided doesn't
require new syntax, it works, and it does something that I think is
*very* useful. I'll reproduce his example here:


This is simple and so unexpected, to me at least, that it seems
brilliant (forget the :returns bit, it is irrelevant). I think I'm
still not used to what can be done with the mixing of compilation and
runtime in ruby.

I tried writing a toy implementation of this last night to see if
it'll solve a problem that I'm going to have to deal with soon. I'm
working on a system that automatically augments class definitions and
this is a great way for a programmer to provide additional hints and
fine-tuning control -- in fact, this opens up a lot of possibilities.
The implementation I came up with requires that include/extend trick
that Robert Klemme mentioned in the "class method aliasing" thread
the other day, but still. I'll soon cheat and look at what nitro and
facets did.

Cheers,
Bob

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

Jeff Wood

------=_Part_5377_16232210.1129824179155--

 

[Paul Brannan]

I agree. See the thread "Anonymous methods, blocks etc. (Cont.
'default block params')" starting at ruby-talk/160709 for some recent
discussion about this.

[ruby-talk:150709] is what I think you meant. The discussion actually
stems from the ruby-dev summary in [ruby-talk:150581].

That's an interesting idea. It would certainly be orthogonal. However,
you can already do that with define_method:

class Foo
a = 42
define_methodfoo) do |b, c|
puts a, b, c
end
end

Foo.new.foo(1,2)
__END__
42
1
2

define_method takes a block, which currently passes arguments by
multiple assignment. That's not what we want. You are right that we
could use define_method, but I think it would look more like this:

a = 42
l = lambda (b, c=10) { puts a, b, c }
define_methodfoo, &l)

Currently, the following code works fine: [snip]
But I would imagine that if lambda were a keyword this would confuse the
parser.

Well, I doubt it would break ~much~ code. It would be quite an unusual
thing to define a function named lamdba(), no?

I agree that it would not break much code. But it must be considered,
even if this is the conclusion.

[snip discussion about || vs <> block local syntax]

I think you're on a losing wicket here. It seems that the zeitgeist is
with the semi-colon to introduce block locals.

My point was that the distintion we want to make is between passing
block arguments through multiple assignment and passing block arguments
method style, rather than between anonymous procs and anonymous
functions/closures. The two differ only in how their arguments are
passed; the syntax IMO should reflect that.

I wasn't intending to make a point about block-locals; I thought they
were a side-effect (but perhaps I was wrong).

With argument passing through multiple assignment (|...|), it is okay
for block parameters to not be block-local. The result is that the
variable gets assigned. Matz has previously stated that all block
parameters will be block-local; he may change (or have already changed)
his mind; I pointed it out because it may or may not remain as is.

With passing arguments method-style (what I was using <...> for, though
I know that syntax has some issues), block parameters probably shouldn't
be block-local. My thought was that if you're not going to use multiple
assignment for argument passing, you shouldn't use assignment at all.
The only way around the assignment is to create a new variable that is
block-local.

Paul