Anonymous methods, blocks etc. (Cont. 'default block params')

[Zach Dennis]

Austin Ziegler wrote:

[snip]

I just
don't particularly care for the proposed syntax:

anon = ->(x = 5) { ... }

Was there an RCR for this syntax? If so what is it's name, I do not see
it on rcrchive.net ?

Zach

 

[Trans]

Was there an RCR for this syntax? If so what is it's name, I do not see
it on rcrchive.net ?

It's Matz' baby; borrwoed from Perl. So no RCR required.

T.

 

[Zach Dennis]

It's Matz' baby; borrwoed from Perl. So no RCR required.

Is the -> syntax still open for debate Matz? I agree with Austin on
this. The syntax here is just ugly.

Zach

 

[Zach Dennis]

Is the -> syntax still open for debate Matz? I agree with Austin on
this. The syntax here is just ugly.

I wanted to partially rephrase this last comment in case it comes across
the wrong way. Is the syntax open for debate at all? If not then I
respectfully withdraw any further arguments on my behalf on this topic.
If it is open for debate, then I'd like to voice my opinion as others
have already, that I would rather prefer a more elegant syntax.

Thanks,

Zach

 

[Daniel Schierbeck]

I wanted to partially rephrase this last comment in case it comes across
the wrong way. Is the syntax open for debate at all? If not then I
respectfully withdraw any further arguments on my behalf on this topic.
If it is open for debate, then I'd like to voice my opinion as others
have already, that I would rather prefer a more elegant syntax.

Thanks,

Zach

I agree. The `->(args) {}' syntax is cluttered and hard to read. The
best solution would be to make the parser work with default values for
block arguments. I know that will take some work, but it's by far the
most elegant and consistent solution.

lambda { |a, b = nil| ... }


Cheers,
Daniel

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Anonymous methods, blocks etc. (Cont. 'default block params')"

|Is the -> syntax still open for debate Matz? I agree with Austin on
|this. The syntax here is just ugly.

It's always open. But define "ugly" first.

matz.

 

[zdennis]

Hi,
=20
In message "Re: Anonymous methods, blocks etc. (Cont. 'default block pa= rams')"

=20
|Is the -> syntax still open for debate Matz? I agree with Austin on=20
|this. The syntax here is just ugly.
=20
It's always open. But define "ugly" first.
=20
matz.

Here are some of my thoughts on the syntax "->(a=3D5,b=3D1){ }" to denote=
it as ugly.
* -> is not a common construct in any language that I know of to repres=
ent anonymous function=20
declaration, while lambda is. Instead -> is a recognized operator for der=
eferencing
* -> can be hard for readability given code like:
m=3D->(a,b){a**b}
OR
m=3D->(a,b){ arr =3D [];a.times { |i| arr << i**b } }

in my opinion it is easier to visually separate such constructs utili=
zing identifiable word=20
construct like lambda:
m=3Dlambda(a,b){ a**b }
OR
m=3Dlambda(a,b) {
arr =3D []
a.times { |i| arr << i**b }
}

* utilizing other operators such as assignment or comparison (although =
I don't know where someone=20
would use comparison operators here) cause visual confusion, and makes it=
easier for programmer to=20
overlook the correct interpretation of the code:
m=3D->(a,b){ .. } sort of looks like m=3D>a(b){ ...block here..=
}
whereas
m=3Dlambda(a,b){ ... } is hard to confuse with any other operator=
s

* Aesthetically, in my opinion -> as an operator is not as elegant as o=
ther ruby constructs such=20
as things like:
lambda { }
proc { }
do ... end
:symbol

The one area where there is another such constructor is with regular =
expressions, /.../, but=20
that seems to be universally used construct for regular expressions.

Now if you do not agree with my opinions and you choose to keep -> would =
it be possible to have:
->(a,b){ .. }
and
lambda(a,b){ }

have the same behavior?

On another note of the questions raised by your blog and translated by _w=
hy the following questions=20
are statement is set forth:

"He wants a good idea which fulfill below condition:
* It=92s able to express anonymous function.
* It puts in front of parameters.
* It=92s good mix of sign which have not been used until now.
* Many people feel comfortable (if possible)."

Would the following example fulfill the first two capabilities and potent=
ially the fourth?
proc =3D lambda (a, b=3D5){ a**b }

If you do not want to change behavior of lambda, I have another question.=
proc_lambda just calls=20
proc_alloc. It looks like proc_lambda is either being used as a placehold=
er for a better=20
implementation (anonymous function?) or it was just an easy way to implem=
ent lambda and make people=20
happy a few years ago.?

Also, according to your examples of using "->" with blocks. Example:
for list -> x { ... }
hash.each -> (k,v=3D"none") { ... }

I do not think the "->" can be used in:
proc =3D -> (x, y) { ... }

and keep the same consistency and clarity. Also would the following repla=
ce existing block syntax?
hash.each -> (k,v=3D"none") { ... }

Or would the above code and the existing block syntax both remain?

In your blog Matz you mention that you are considering -> operator becaus=
e of Perl6. Ruby has a=20
strong user base now and it is growing. People like many of the similarit=
ies that Ruby has with=20
Perl, but many of those same people are very happy that you did not pull =
over things from Perl like=20
hash or array dereferencing. I think the -> operator is one of these spo=
ts where it should be left=20
in Perl. Let perl people use ugly symbol based operators so it can add co=
nfusion, let ruby people=20
use something better. Also I do not claim to know what the better is. Per=
haps it is lambda, perhaps=20
it is something else....

Thank you for your time Matz to review this.

Zach

As references I reviewed the following sources:
- http://redhanded.hobix.com/inspect/blockAndLambda.html
- http://www.rubyist.net/~matz/?date=3D20050722 (babelfish translation, s=
imilar to redhanded blog above)
- http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/161133 (the=
whole thread)
-

 

[Martin DeMello]

in my opinion it is easier to visually separate such constructs
utilizing identifiable word construct like lambda:

I mentioned Arc's use of fn for lambda a year or two ago, but Matz felt
it wasn't a conservative enough change for Ruby. Might be worth
considering now, though on the flip side it'd promote fn to a keyword
and conceivably break some code in the process.

martin

 

[Gavin Kistner]

Here are some of my thoughts on the syntax "->(a=5,b=1){ }" to
denote it as ugly.

My additions (as another non-fan of this syntax):
* It's a pain to type on a US English keyboard. Under 'proper'
typing, I believe the right right finger is required for both
characters, timed with a shift key press for the second one. Despite
the verbosity, I find typing "lambda" to be faster than typing "->".
And "def" is even easier

* It points the wrong way. I don't know how to convince anyone of
this, but in my heart of hearts it's like a right hand side missing
it's left. With something like: foo = <- (a,b){ ... } it
looks like the arrow takes all the stuff on the right hand side and
converts it into something that's available on the left hand side.
The syntax being discussed can only be justified (by me) as some sort
of symbolic link or something. "You were expecting a value here?
Quick, look to the right!"

Ugly, like beauty, is in the eye of the beholder. Sometimes it's hard
to quantify or rationalize. It's just...ugly (to me).

 

[Trans]

This is abit to the side, but maybe it would shed light on the
discussion. I'm wondering why lambda's can't be like more methods. If I
define a method:

def meth ; 1 ; end

and then type

meth #=> 1

The output is immediate, 1. But with a lambda, i.e. an aynnomous
method, this is not the case.

lam = lambda do ; 1 ; end
lam #=> #<Proc...>

To get hold of a first class method we have to do methodmeth). Many
of us have wanted something briefer (of course this ties into the whole
UnboundMethod/Method/Lambda/Proc/Block craziness, nontheless...) So why
not have the two on the same footing then?

lam = lambda do ; 1 ; end
lam #=> 1

And to get a reference to the actual lambda object maybe

&lam

and we can do it for methods:

&meth #or &self.meth as the case may warrent

I know that usually turns a lambda into a block, but in essense isn't
that the same thing? Well if not then use another symbol. The important
thing is now its clean and much more useful. We can actually drop in
lambdas for local vars without perceptable difference. Very cool! Very
useful!

Okay, so how does this get back to the case at hand. Interestingly it
would mean:

def x ; 1 ; end

and

x = lambda do ; 1 ; end

mean almost the same thing, except for two distinctions: 1) the lambda
has closure, and 2) the lamda's x is a local var, while the def's x is
on the instance level, like @x. And that's very interesing b/c that
means

def initialize
@x = lambda do ; 1 ; end
end

@x is like having a local instance method!

It also indicates that #def is like a method taking a special parameter
'x' --just like define-method:

def( :x ) do ; 1 ; end

So I think it's reasonable to deem that if that parameter is not given
then it is annonymous so:

x = def() do ; 1 ; end

This is very much like what Dave suggested. And like him this def I
imagine this should be *non-closure*. And we need another name for
closure, that could be 'lambda', okay, but I'd prefer somthing shorter,
like 'fn' or maybe with three letters like 'def' so maybe 'dfn'

x = dfn do ; 1 ; end

Of course these are special and should be keywords so then we can drop
the 'do'. The only thing that sets them a part from other methods is
that with 'def' a special parameter can appear in the front of the
parameters to define an instance level name, i.e. the method name. I
suppose the same can be done for dfn is we want to keep the closure.

class X
name = self.name
dfn x ; name ; end
end

X.new.x #=> "X"

I think that solves just about all the signifficant issues related to
this. If Matz want's an '->' operator to basically mean 'dfn', that's
his call, but I think maybe most people will be happier with a word
form.

Sorry to go on so long, but I HTH.
T.

 

[gwtmp01]

To get hold of a first class method we have to do methodmeth). Many
of us have wanted something briefer (of course this ties into the
whole
UnboundMethod/Method/Lambda/Proc/Block craziness, nontheless...) So
why
not have the two on the same footing then?

lam = lambda do ; 1 ; end
lam #=> 1

Something tells me that it will be impossible to have an identical
syntax for all of:

1) local variable
2) 0-argument method invocation
3) formal parameters
4) 0-argument Proc#call invocation

It is pretty easy to package up define_method and have a very concise
way
to define methods on demand. This lets you associate a block with a
name (a method name) at will. The only "gotcha" is that you are working
within the namespace of the object's methods and not the namespace of
the the method itself (as with local variables).

class A
def fn(symbol, &block)
(class <<self; self; end).senddefine_method, symbol, &block)
end
def method_missing(symbol, *args, &block)
fn(symbol, &block)
end

def m1
m2 {|n| 2*n}
fnm3){|n| 3*n }

puts m2(4) # -> 8
puts m3(4) # -> 12
end
end

A.new.m1






Gary Wright

 

[Ron M]

Here are some of my thoughts on the syntax "->(a=5,b=1){ }" to denote it
as ugly.
* -> is not a common construct in any language that I know of to

Seems that creating an anonymous function has one of the most widely
varying syntaxes of all language features as can be seen by this table:

http://merd.sourceforge.net/pixel/language-study/syntax-across-languages.html#FnctnnnmsFnct

Seems "->" appears in a few places (Perl6 looks very much like Ruby,
and -> appears as part of Haskell, OCaml and Erlang's syntaxes for
anonymous functions) so it's not totally unique, but only Perl6
puts the "->" at the beginning of the expression like the proposed
Ruby one.

represent anonymous function declaration, while lambda is. Instead -> is
a recognized operator for dereferencing

I wouldn't say Lambda's that common. For creating anonymous
functions variations of the word "function" ("func", "fun", "fn",
"function", "create_function") seem to appear across more languages
than "lambda". And if you're looking towards well-known languages,
C#'s "(a,b)=>" syntax is probably the winner.



There's so little commonality across languages that I think this will be
an objection no matter what syntax is used.



(For people who don't know that site already, this survey of syntax
across languages
http://merd.sourceforge.net/pixel/language-study/syntax-across-languages/
it's a very nice reference compare commonalities of various computer languages)

 

[Trans]

Hi--

Something tells me that it will be impossible to have an identical
syntax for all of:

1) local variable
2) 0-argument method invocation
3) formal parameters
4) 0-argument Proc#call invocation

What do you mean by #3? Other than that why so you see this as problem?
If a method and a local var can be the same why not annoynous method
with local var name? The trick is simplly like that of dealing with
blocks --though I realize now some other symbolization will be needed
to differentiate block from passing first-class lambda object. I'm
gogin to use Matz notation here for lack of anything else
(interestingly it actually makes some sense as "dereference")

def pass_it_on( x )
x # calls it
->x # returns it back
end

inc = ->(x){ x+1 }

pass_it_on( ->inc )

So to pass a lambda around you just prefix it. Interesing thing you can
do is easy lazy evaluation:

def diff( a, b )
a - b
end

sec = ->{ sleep 1 ; Time.now.sec }

diff( ->sec, ->sec ) #=> 1, or there abouts

This can be applied to methods to, eg.

def mymeth(a,b,c)
# ...
end

def mymeth_size
->mymeth.arity
end

It is pretty easy to package up define_method and have a very concise
way to define methods on demand. This lets you associate a block with a
name (a method name) at will. The only "gotcha" is that you are working
within the namespace of the object's methods and not the namespace of
the the method itself (as with local variables).

class A
def fn(symbol, &block)
(class <<self; self; end).senddefine_method, symbol, &block)
end
def method_missing(symbol, *args, &block)
fn(symbol, &block)
end

def m1
m2 {|n| 2*n}
fnm3){|n| 3*n }

puts m2(4) # -> 8
puts m3(4) # -> 12
end
end

A.new.m1

Sure, but this is very weak by comparision. Your using method_missing
for one, and as you say your defining methods into the singleton space,
not anonymously. Ruby has all sorts of "tricks", but this isn't a
suitable general solution.

T.

 

[gwtmp01]

What do you mean by #3? Other than that why so you see this as
problem?

Right now there are some heuristics that allow the ruby parser to
decide how to interpret an identifier with no associated arguments.
In particular if it matches the name of a formal argument or it has
appeared on the left hand side of an assignment, the parser assumes
it is a variable. Otherwise it assumes it is a 0-argument method call.

Even with these rules we sometimes have to help the parser out by
explicitly indicating that it is a method call:

self.attribute = value # to avoid creating a local var
'attribute'

You are proposing that there be yet another interpretation that
combines the behaviour of a variable with the semantics of a 0-argument
method call:

magic_id

gets interpreted as

magic_id.method

but only if magic_id happens to be a reference to a particular kind
of object (an "anonymous method"). Since there doesn't seem to be
a syntactical way to spot an identifier with this magic behavior
(indeed I believe you are asserting that the power of the proposal comes
from the fact that there is *no* syntactical difference), then you
are implying some sort of runtime check each and every time the
identifier
is evaluated.

During this evaluation the "magic" occurs. If the identifier actually
references a special type of object then there is an implicit call
to an predetermined method that results in a previously defined block/
closure
being executed. The value yielded by this block "becomes" the value
associated with the identifier. In other words, 'magic_id' gets
automatically interpreted as:

magic_id.call

If a method and a local var can be the same why not annoynous method
with local var name?

I'm not sure I'm understanding your use of the term 'anonymous method'.
I *think* it is something between a block/closure and a Proc object
but it isn't either? Can you explain how it differs from a standard
Proc object or is the difference just in the alternative invocation?

The trick is simplly like that of dealing with
blocks --though I realize now some other symbolization will be needed
to differentiate block from passing first-class lambda object.

So you are proposing some manner of reifying a block but you don't
want to utilize a Proc object but some other new type of object?

I'm
gogin to use Matz notation here for lack of anything else
(interestingly it actually makes some sense as "dereference")

Matz notation is just a way of allowing Proc objects to have the
same argument passing semantics/syntax as regular methods. It still
ends up creating a Proc object and still requires an explicit
invocation of Proc#call to execute the associated block.

You replied:

Sure, but this is very weak by comparision. Your using method_missing
for one, and as you say your defining methods into the singleton
space,
not anonymously.

I just used method missing to make the *definition* simpler. The
resulting
invocation syntax is the same regardless of how it is defined.

I'm not sure how your method makes anything anonymous. You are just
proposing
that a specific method be called under certain conditions in the way
#to_proc
is called on an argument prefixed with & or in the way #to_a is
called when
the 'splat' operated is used. #to_proc and #to_a aren't anonymous
they are
just invoked indirectly according to the syntactical rules of the
language.


Gary Wright

 

[Martin DeMello]

To get hold of a first class method we have to do methodmeth). Many
of us have wanted something briefer (of course this ties into the whole
UnboundMethod/Method/Lambda/Proc/Block craziness, nontheless...) So why
not have the two on the same footing then?

lam = lambda do ; 1 ; end
lam #=> 1

And to get a reference to the actual lambda object maybe

&lam

and we can do it for methods:

&meth #or &self.meth as the case may warrent

This breaks ruby's model quite badly, though. If a lambda is a function
object, then any variable pointing to it should 'return' the object when
used.

martin

 

[Trans]

Martin,

Ruby's model? I realize this is significant change, and not backwards
compatible.

I am suggesting lamda as true "define anonymous method". Since 'lambda'
means 'function' I do not think it neccesitates a meaning of 'object'.
You are playing with words. It is not unreasonable to require a
"dereference" to get a 1st class object --just as we do with methods.
And it has powerful ploymorphic usecase.

T.

 

[Trans]

Right now there are some heuristics that allow the ruby parser to
decide how to interpret an identifier with no associated arguments.
In particular if it matches the name of a formal argument or it has
appeared on the left hand side of an assignment, the parser assumes
it is a variable. Otherwise it assumes it is a 0-argument method call.

Even with these rules we sometimes have to help the parser out by
explicitly indicating that it is a method call:

self.attribute = value # to avoid creating a local var
'attribute'

Right. And that's all it needs to do here. Nothing in this respect
changes.

You are proposing that there be yet another interpretation that
combines the behaviour of a variable with the semantics of a 0-argument
method call:

magic_id

gets interpreted as

magic_id.method

but only if magic_id happens to be a reference to a particular kind
of object (an "anonymous method"). Since there doesn't seem to be
a syntactical way to spot an identifier with this magic behavior
(indeed I believe you are asserting that the power of the proposal comes
from the fact that there is *no* syntactical difference), then you
are implying some sort of runtime check each and every time the
identifier is evaluated.

During this evaluation the "magic" occurs. If the identifier actually
references a special type of object then there is an implicit call
to an predetermined method that results in a previously defined block/
closure being executed. The value yielded by this block "becomes" the value
associated with the identifier. In other words, 'magic_id' gets
automatically interpreted as:

magic_id.call

I think you've made this appear more complicated than it is. It's not
so magical. A var references an object, so this amount to nothing more
than (psuedo)

var.lamda? ? var.call ? var

under the hood. And I am sure there is very fast way to do this. Also,
there's actually no reason we can't have both forms, though I think
that might be less attractive for the language as a whole.

lam = dfn ; 1 ; end
lam1stclass = ->lam

I'm not sure I'm understanding your use of the term 'anonymous method'.
I *think* it is something between a block/closure and a Proc object
but it isn't either? Can you explain how it differs from a standard
Proc object or is the difference just in the alternative invocation?

The use of term is just what its called in the sense that it is not
tied to the method table, but to a free varaible. So this is possible:

a = []
a[1] = dfn ; 1 ; end

Ie. No fixed name. What they "are" is simply what Matz has designated
them as --they are methods except they do not have the fixed name and
they have closure. They differ from Proc only in subtle ways.

So you are proposing some manner of reifying a block but you don't
want to utilize a Proc object but some other new type of object?

I'm only proposing a different way of *referencing* what Matz is
already reifying.

Matz notation is just a way of allowing Proc objects to have the
same argument passing semantics/syntax as regular methods. It still
ends up creating a Proc object and still requires an explicit
invocation of Proc#call to execute the associated block.

I realize. I was simply "borrowing" the notaiton. But I was delighted
at how well it worked.

You replied:

I just used method missing to make the *definition* simpler. The
resulting
invocation syntax is the same regardless of how it is defined.

I'm not sure how your method makes anything anonymous. You are just
proposing
that a specific method be called under certain conditions in the way
#to_proc
is called on an argument prefixed with & or in the way #to_a is
called when
the 'splat' operated is used. #to_proc and #to_a aren't anonymous
they are
just invoked indirectly according to the syntactical rules of the
language.

Don't let the word "anonymous" get in the way --that just refers to the
fact it is a method kept independent of the method table. Nothing more.

Part of this idea has already been expiremented with in 1.9 with

a = proc { 1 }
a() #=> 1

But this way doesn't do us as much good, and has serious issues b/c 'a'
is still the Proc object direct. Thus this "feature" was recently
removed. I'm offering an improved alternative, if you will.

T.

 

[Trans]

Martin,

Ruby's model? I realize this is significant change, and not backwards
compatible.

Actually that's not exactly true. It is only not backwards comapitable
if preexisting keyword/methods are used. Namely:

lambda { ... }

Just don't reuse that but use new term as I also suggest, like 'dfn'
and matz' '->'.

T.

 

[gwtmp01]

I think you've made this appear more complicated than it is. It's not
so magical. A var references an object, so this amount to nothing more
than (psuedo)

var.lamda? ? var.call ? var

under the hood. And I am sure there is very fast way to do this.

Even if there is a fast way of doing it, I think your proposal requires
that it be done for *every* expression. The only way to avoid that
would be some sort of data-flow analysis to discover which variables
don't reference one of these Proc-like objects.

But I think there is a bigger problem. If I'm following you, you
suggested
that there would be a special syntax to indicate that the Proc-like
object *not* be called but instead be returned as a references. You
wrote:

def pass_it_on( x )
x # calls it
->x # returns it back
end

So now you are in a sense reversing the syntax of ruby such that
you need an explicit marker to *not* call the implied object/method.
But there is no way to know when you need to use that syntax unless
you already know that the reference contains this special object. For
example

def proxy(a, b, c)
actual(a, b, c)
end

def actual(e, f, g)
e + f + g
end

proxy(dfn; 1; end, dfn; 2; end, dfn 3; end)

Where do the three "anonymous methods" get evaluated? In proxy
before the call to actual or in actual before the call to '+'
or somewhere in '+' itself?

The use of term is just what its called in the sense that it is not
tied to the method table, but to a free varaible. So this is possible:

a = []
a[1] = dfn ; 1 ; end

So it is just an object, which has it's own set of methods. But one
of those methods call ?) gets executed whenever the reference gets
evaluated and you can defer the evaluation by prepending '->'.

I don't see how the object you are proposing can be passed around
since as
soon as you omit the '->' prefix it is going to get evaluated and
result in a 'regular' reference to some object.

Gary Wright

 

[Trans]

Even if there is a fast way of doing it, I think your proposal requires
that it be done for *every* expression. The only way to avoid that
would be some sort of data-flow analysis to discover which variables
don't reference one of these Proc-like objects.

But I think there is a bigger problem. If I'm following you, you
suggested
that there would be a special syntax to indicate that the Proc-like
object *not* be called but instead be returned as a references. You
wrote:

def pass_it_on( x )
x # calls it
->x # returns it back
end

So now you are in a sense reversing the syntax of ruby such that
you need an explicit marker to *not* call the implied object/method.
But there is no way to know when you need to use that syntax unless
you already know that the reference contains this special object. For
example

def proxy(a, b, c)
actual(a, b, c) # <== HERE
end

def actual(e, f, g)
e + f + g
end

proxy(dfn; 1; end, dfn; 2; end, dfn 3; end)

Where do the three "anonymous methods" get evaluated? In proxy
before the call to actual or in actual before the call to '+'
or somewhere in '+' itself?

Since Ruby evaluates expressions in passing args then they'd be
evaluated prior to passing to actual method.

You are right in that there is a caveat for having this in that you
need to know that they are going to be "anonymous methods" in order to
pass them around. But the same is true for calling a proc, i.e. you
have to know it's a proc to call it. In cases of uncertainity a "meta
method" (like block_given?) could be helpful.

def proxy(a)
if lambda? a
actual(->a)
else
actual(a)
end
end

I imagine a means of supressing all expression evaluations in an
invocation might be possbile too, though I'm not sure how it might be
notated.

The use of term is just what its called in the sense that it is not
tied to the method table, but to a free varaible. So this is possible:

a = []
a[1] = dfn ; 1 ; end

So it is just an object, which has it's own set of methods. But one
of those methods call ?) gets executed whenever the reference gets
evaluated and you can defer the evaluation by prepending '->'.

I don't see how the object you are proposing can be passed around
since as
soon as you omit the '->' prefix it is going to get evaluated and
result in a 'regular' reference to some object.

I see your point. It can be executed implicitly but has to be passed
around explicitly, reverse of current lambda which can be passed around
implicitly but must be executed explicitly. So maybe this would not
make a good wholescale replacement for 1st class lambdas b/c somethings
might be more awkward --I'd have to explore it more to be sure. But if
these "implicit lambdas" can work without any significant pressure on
the interpretor (and as you point out, its imilar to singleton methods
so maybe it can), they could be a useful additional feature.

T.