Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ruby-dev summary 28274-28600

0 views
Skip to first unread message

APURI Furuhashi

unread,
Apr 1, 2006, 3:43:05 AM4/1/06
to
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

unread,
Apr 1, 2006, 6:02:54 AM4/1/06
to
APURI Furuhashi schrieb:

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

unread,
Apr 1, 2006, 9:07:33 AM4/1/06
to

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


Trans

unread,
Apr 1, 2006, 9:09:41 AM4/1/06
to
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

unread,
Apr 1, 2006, 9:14:23 AM4/1/06
to
> 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

unread,
Apr 1, 2006, 9:18:20 AM4/1/06
to
Mauricio Fernandez schrieb:

OK. Now I'm feeling better :-)

Regards,
Pit


ara.t....@noaa.gov

unread,
Apr 1, 2006, 9:54:36 AM4/1/06
to
On Sat, 1 Apr 2006, APURI Furuhashi wrote:

> 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


Yukihiro Matsumoto

unread,
Apr 1, 2006, 11:43:27 AM4/1/06
to
Hi,

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.


ara.t....@noaa.gov

unread,
Apr 1, 2006, 11:59:34 AM4/1/06
to
On Sun, 2 Apr 2006, Yukihiro Matsumoto wrote:

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

Yukihiro Matsumoto

unread,
Apr 1, 2006, 12:32:21 PM4/1/06
to
Hi,

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.


ara.t....@noaa.gov

unread,
Apr 1, 2006, 12:47:38 PM4/1/06
to
On Sun, 2 Apr 2006, Yukihiro Matsumoto wrote:

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

Trans

unread,
Apr 1, 2006, 3:40:00 PM4/1/06
to
> btw. whatever it is called this will be a very nice feature to have!

A good name mught be __1ST__.

T.

ara.t....@noaa.gov

unread,
Apr 1, 2006, 4:07:15 PM4/1/06
to

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

Trans

unread,
Apr 1, 2006, 7:15:55 PM4/1/06
to
> A good name mught be __1ST__.

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

T.

Trans

unread,
Apr 1, 2006, 7:23:28 PM4/1/06
to

ara.t....@noaa.gov wrote:
> On Sun, 2 Apr 2006, Trans wrote:
>
> >> 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??

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

unread,
Apr 1, 2006, 8:01:17 PM4/1/06
to
ara.t....@noaa.gov 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?

0 new messages