[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Unification of variables and methods

Yukihiro Matsumoto

2/17/2007 6:02:00 AM

Hi,

In message "Re: Unification of variables and methods"
on Sat, 17 Feb 2007 14:16:24 +0900, Charles Lowe <aquasync@gmail.com> writes:

|The one thing that bothers me about ruby is the (as i see it?) separate
|namespaces for locals and functions.

I think unification makes

obj.foo

to retrieve foo method object a la Python, which I believe is not the
best way for programmers. In short, I took CommonLisp way over
Scheme way.

Some points you have pointed are negotiable.

matz.

1 Answer

Charles L.

2/23/2007 6:41:00 AM

0

Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: Unification of variables and methods"
> on Sat, 17 Feb 2007 14:16:24 +0900, Charles Lowe
> <aquasync@gmail.com> writes:
>
> |The one thing that bothers me about ruby is the (as i see it?) separate
> |namespaces for locals and functions.
>
> I think unification makes
>
> obj.foo
>
> to retrieve foo method object a la Python, which I believe is not the
> best way for programmers. In short, I took CommonLisp way over
> Scheme way.
>
> Some points you have pointed are negotiable.
>
> matz.

Thanks for the response. In some ways i suppose, I've always found
scheme somehow more elegant that commonlisp, so perhaps we are looking
for different things...

I think though, that unification of vars/methods, and whether a bare
method name should auto-apply (as it were) are orthogonal? And I
certainly don't advocate the removal of the latter (ie obj.foo returning
a method object). That is part of what gives ruby its beauty IMO.
A unified namespace does pave the way for () to map to #call (although
such semantics aren't required), and it doesn't preclude the use of
plain methods.
Rather consider something like this:

def foo
...
end

bar = proc { ... }

foo # calls a method
foo() # also calls a method
method(:foo) # gets method object (proc)
bar # gets a proc
bar() # calls that proc

Its merely a syntactic sugar i guess, but in a way, you then have the
option of doing things python style, which is not my intention, and
possibly undesirable.

I think that the semantics are neater in the before mentioned case of
collisions:

def x; 1; end
x = 2
x # => 2
x() # => 1

If that final one were to either try to #call the x variable, or throw a
runtime error, or something, it would be (IMO of course) better.

In order to try to fake it for local variables, i tried this hack
once-upon-a-time:

def method_missing(sym, *args, &block)
sym = sym.to_s
error = NameError.new "undefined local variable or method `#{sym}'"
Binding.of_caller do |binding|
raise error unless eval('local_variables', binding).include?
sym.to_s
func = eval(sym, binding)
raise error unless func.respond_to? :call
func.call(*args, &block)
end
end

At any rate, just glad you've considered it - Ruby is great, so I trust
your judgement :)


--
Posted via http://www.ruby-....