This is a summary of ruby-dev ML in these days.
[ruby-dev:28246] Named Capture for Regexp
K. Kosako proposed a new /g and /G flag for regexp,
to refer to the result of named capture by the name to Ruby 1.9
Meaning is as follows.
1. When neither is specified (default), capture of the group of
the name.
2. /g is specified. The group of the name doesn't do capture.
3. /G is specified. The group of the name does capture.
The discussion keeps going.
[ruby-dev:28481] __method__ for current method
Usa Nakamura suggested a new method __method__ to access name of
currently executing method. The name is chosen to go with __FILE__ and
__LINE__ but it's a method not syntax.
[ruby-dev:28533] Multi Methods
URABE Shyouhei proposed a rough idea for multi methods (in lisp as
generic function) for ruby
The syntax is
def foo( SPEC val)
SPEC is any object which respond to "===".
This allow multiple dispatch class based or like eql? specializer in
lisp.
But if ther is not a matching SPEC beetween all methods it is still
called, for duck typing.
Matz said he agrees and this can be committed to 1.9 if it is
fast implementation.
-- APURI Furuhashi
ruby-dev summary index: http://i.loveruby.net/en/ruby-dev-summary.html
Will there be a defined sequence for calling the "===" methods?
If there are multiple matching definitions, which one(s) would be called?
Regards,
Pit
See
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/28533
(and the Date: header)
--
Mauricio Fernandez - http://eigenclass.org - singular Ruby
class Bar
def foo( String x )
...
def foo( Integer x )
...
Right?
> If there are multiple matching definitions, which one(s) would be called?
And how would you reference them via method()?
T.
Hmmm.... I had used #this for this purpose. But often I just need the
name of the method. If I have the name I can always do
'method(methodname)' --though the multidispatch thing might effect that
now too.
T.
OK. Now I'm feeling better :-)
Regards,
Pit
> Hi all,
>
> This is a summary of ruby-dev ML in these days.
>
> [ruby-dev:28246] Named Capture for Regexp
>
> K. Kosako proposed a new /g and /G flag for regexp,
> to refer to the result of named capture by the name to Ruby 1.9
> Meaning is as follows.
> 1. When neither is specified (default), capture of the group of
> the name.
> 2. /g is specified. The group of the name doesn't do capture.
> 3. /G is specified. The group of the name does capture.
> The discussion keeps going.
>
>
>
>
> [ruby-dev:28481] __method__ for current method
>
> Usa Nakamura suggested a new method __method__ to access name of
> currently executing method. The name is chosen to go with __FILE__ and
> __LINE__ but it's a method not syntax.
why not be consistent
harp:~ > cat a.c
#include <stdlib.h>
#include <stdio.h>
main () { printf ("%s:%s:%d\n", __FILE__, __FUNCTION__, __LINE__); }
harp:~ > gcc a.c && a.out
a.c:main:3
> [ruby-dev:28533] Multi Methods
>
> URABE Shyouhei proposed a rough idea for multi methods (in lisp as
> generic function) for ruby
> The syntax is
> def foo( SPEC val)
> SPEC is any object which respond to "===".
> This allow multiple dispatch class based or like eql? specializer in
> lisp.
>
> But if ther is not a matching SPEC beetween all methods it is still
> called, for duck typing.
> Matz said he agrees and this can be committed to 1.9 if it is
> fast implementation.
can any one show an example of what this might look like in ruby?
regards.
-a
--
share your knowledge. it's a way to achieve immortality.
- h.h. the 14th dali lama
In message "Re: ruby-dev summary 28274-28600"
on Sat, 1 Apr 2006 23:54:36 +0900, ara.t....@noaa.gov writes:
|> [ruby-dev:28481] __method__ for current method
|>
|> Usa Nakamura suggested a new method __method__ to access name of
|> currently executing method. The name is chosen to go with __FILE__ and
|> __LINE__ but it's a method not syntax.
|
|why not be consistent
|
| harp:~ > cat a.c
| #include <stdlib.h>
| #include <stdio.h>
| main () { printf ("%s:%s:%d\n", __FILE__, __FUNCTION__, __LINE__); }
|
|
| harp:~ > gcc a.c && a.out
| a.c:main:3
Because we don't have real functions but methods in Ruby.
matz.
> |why not be consistent
> |
> | harp:~ > cat a.c
> | #include <stdlib.h>
> | #include <stdio.h>
> | main () { printf ("%s:%s:%d\n", __FILE__, __FUNCTION__, __LINE__); }
> |
> |
> | harp:~ > gcc a.c && a.out
> | a.c:main:3
>
> Because we don't have real functions but methods in Ruby.
>
> matz.
i see your point... still, it seems to cut both ways:
harp:~ > ruby -e' p [__FILE__, __LINE__]; eval "p [__FILE__, __LINE__]" '
["-e", 1]
["(eval)", 1]
In message "Re: ruby-dev summary 28274-28600"
on Sun, 2 Apr 2006 01:59:34 +0900, ara.t....@noaa.gov writes:
|i see your point... still, it seems to cut both ways:
|
| harp:~ > ruby -e' p [__FILE__, __LINE__]; eval "p [__FILE__, __LINE__]" '
| ["-e", 1]
| ["(eval)", 1]
I'm not sure what you meant. Do you mean both should print
["-e", 1] ? If so, what do you want to print by:
p "__FILE__ __LINE__"
? Or what if
def foo(x)
eval(x)
end
.. and in some other file...
foo("p [__FILE__, __LINE__]")
?
matz.
> I'm not sure what you meant. Do you mean both should print
> ["-e", 1] ? If so, what do you want to print by:
>
> p "__FILE__ __LINE__"
>
> ? Or what if
>
> def foo(x)
> eval(x)
> end
>
> ... and in some other file...
> foo("p [__FILE__, __LINE__]")
>
> ?
> matz.
sorry i wasn't clear.
i just meant that even though ruby does not have real functions using
__FUNCTION__ (and alias __METHOD__) seems to be o.k. since
- it inherits idea from c like __FILE__ and __LINE__
- __FILE__ and __LINE__ work even when there is no 'real' file or line
(unlike c) so it seems ok that __FUNCTION__ might work even though there
is no 'real' function ;-)
btw. whatever it is called this will be a very nice feature to have!
A good name mught be __1ST__.
T.
ya know - what might really be good is
callstack #=> array of method objects
where
first = callstack.first
p first.name #=> like __method__
so, like caller but something more valuable than strings...
thoughts??
I was waiting for someone to say, "Or __APRIL__" ;)
T.
Leave it Ara to to turn lemons into lemonade! :)
I argee, Ara. I've wondered about a more object-oriented callstack for
sometime --I've even created one with my TracePoint class. Which I then
use to create a more robust event tracing system (built on top of
set_trace_func).
T.
> ya know - what might really be good is
>
> callstack #=> array of method objects
>
> where
>
> first = callstack.first
> p first.name #=> like __method__
>
>
> so, like caller but something more valuable than strings...
>
> thoughts??
yes, one: I recall Sydney had something like this, i.e. Frame objects
(and BackTrace objects), see for example:
http://hoshi.fallingsnow.net/svn/sydney/trunk/test/sydney/test_frame.rb
I'd love if we could import that, but maybe ruby and sydney diverged too
much in the meanwhile.
Ah, and I guess we're approaching Smalltalk again, is'nt that what they
use "thisContext" for?