[#407] New feature for Ruby? — Clemens.Hintze@...

Hi all,

27 messages 1999/07/01
[#413] Re: New feature for Ruby? — matz@... (Yukihiro Matsumoto) 1999/07/01

Hi Clemens,

[#416] Re: New feature for Ruby? — Clemens Hintze <c.hintze@...> 1999/07/01

On Thu, 01 Jul 1999, Yukihiro Matsumoto wrote:

[#418] Re: New feature for Ruby? — gotoken@... (GOTO Kentaro) 1999/07/01

Hi

[#426] Re: New feature for Ruby? — gotoken@... (GOTO Kentaro) 1999/07/02

Hi,

[#440] Now another totally different ;-) — Clemens Hintze <c.hintze@...>

Hi,

21 messages 1999/07/09
[#441] Re: Now another totally different ;-) — matz@... (Yukihiro Matsumoto) 1999/07/09

Hi,

[#442] Re: Now another totally different ;-) — Clemens Hintze <c.hintze@...> 1999/07/09

On Fri, 09 Jul 1999, you wrote:

[#443] — Michael Hohn <hohn@...>

Hello,

26 messages 1999/07/09
[#444] interactive ruby, debugger — gotoken@... (GOTO Kentaro) 1999/07/09

Hi Michael,

[ruby-talk:00487] Re: coderefs

From: matz@... (Yukihiro Matsumoto)
Date: 1999-07-14 06:07:59 UTC
List: ruby-talk #487
Hi,

In message "[ruby-talk:00486] Re: coderefs"
    on 99/07/13, Michael Hohn <hohn@math.utah.edu> writes:

|as opposed to using the parentheses; something like
|
|   f = obj.method(:method_name)
|   f(args)
|
|would be far cleaner.  Does the syntax f() have a fixed, predefined meaning?  

I agree f(args) is far cleaner than f.call(args), but Ruby tries to
call the method named `f' instead of invoking method object referred
by the local variable `f'.  It's because the namespaces for methods
and variables are separated, like plain lisp, not like scheme.

If there's any workaround, I'd like to know.

                                                matz.

In This Thread