ruby-dev summary 28274-28600

[APURI Furuhashi]

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.

[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

 

[Pit Capitain]

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

Will there be a defined sequence for calling the "===" methods?

If there are multiple matching definitions, which one(s) would be called?

Regards,
Pit

 

[Mauricio Fernandez]

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

Will there be a defined sequence for calling the "===" methods?

If there are multiple matching definitions, which one(s) would be called?

See
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/28533

(and the Date: header)

 

[Trans]

By multi methods I take this to mean:

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.

 

[Trans]

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.

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.

 

[Pit Capitain]

See
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/28533

(and the Date: header)

OK. Now I'm feeling better

Regards,
Pit

 

[ara.t.howard]

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

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 28274-28600"
on Sat, 1 Apr 2006 23:54:36 +0900, (e-mail address removed) 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.

 

[ara.t.howard]

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

regards.

-a

 

[Yukihiro Matsumoto]

Hi,

In message "Re: ruby-dev summary 28274-28600"
on Sun, 2 Apr 2006 01:59:34 +0900, (e-mail address removed) 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.

 

[ara.t.howard]

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!

regards.

-a

 

[Trans]

btw. whatever it is called this will be a very nice feature to have!

A good name mught be __1ST__.

T.

 

[ara.t.howard]

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

-a

 

[Trans]

A good name mught be __1ST__.

I was waiting for someone to say, "Or __APRIL__"

T.

 

[Trans]

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

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.

 

[gabriele renzi]

(e-mail address removed) ha scritto:

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?