"gabriele renzi" <surrender_it / remove.yahoo.it> schrieb im Newsbeitrag
news:hcr0e0l8upivj24bi96vgurn6auv88bmd0 / 4ax.com...
> il Mon, 28 Jun 2004 15:38:03 +0200, "Robert Klemme" <bob.news / gmx.net>
> ha scritto::
>
> >> "p" may stand for self#p, or a local variable named "p".
> >
> >True.  It might be inconsistency then, because for a method "foo" and
> >"foo()" are identical (apart from, that the latter form does not have
the
> >ambiguity) but you proposed change would introduce a significant
> >difference between "foo" and "foo()".
>
> this is true. It feels better to me, somehow, but that's just my
> opinion.

The nice thing about such discussions is that we all can rationalize our
feelings - or discover that they were wrong.

> >You probably guessed that I don't like this very much. :-)
>
> You  don't like my idea! You #?@*
> It's ok for anyone to dislike this, we're just chatting about an idea,
> nothing really important[1] :)

Gulp...  :-)

> >Well, there
> >are also reasons: ruby could no longer determine at compile time the
> >semantics of this code:
> >
> >def foo(x)
> >  x("bar")
> >end
> >
> >Because x("bar") could be a method invocation or it could be an
invocation
> >of the Proc instance x.
> >And since we don't have type declarations in Ruby
> >you couldn't get this to work.  That's especially true because when foo
is
> >defined there need not be a method x at all.
>
>
> I see, even if I fail to see how this is a problem. Say, #x could not
> be defined at the time of #foo call, so ruby has to check for
> something anyway. In what it differs from checking the type of x ?

Ruby determines locally, i.e. considering only the method it currently
compiles, how to interpret artefacts.  It doesn't matter if there is no
method x() if you do "def foo; x("bar"); end"; this is recognized as a
method call.  Only at runtime it is checked whether there is a method x.
But the invocation code is compiled at this stage.

Now, if we introduce your change, Ruby cannot determine whether to compile
the equivalent of self.x("bar") or of x.call("bar") because it's clear
only at runtime what x is.

> >> It is better because it looks like () yet it's worst because it just
> >> mimics something hiding it's meaning,
> >
> >Could you elaborate that?  I don't get the point.  My understanding
was,
> >that you were looking for a nicer more intuitive syntax to invoke a
Proc
> >instance.
>
> not a nicer as in 'less typing'. just nicer as in 'mimic the right
> thing', say:
>
>
> foo 10
> and
> foo(10)
> and
> foo.call 10
>
> all gives me the feeling of a method call/function application, where
> foo[10]
>
> is array indexing to me.

.... or associative lookup (aka Hash).  From a certain point of view this
is pretty much the same: you hand it over some values and get something
back (if you're lucky).

> Obviously the inconsistency is not really removed using the trick I
> propose, just moved somewhere else. It just happens I'd prefer seeing
> it there instead of here :)
>
>
> [1] ok, people use to die for Ideas, but that ones are capitalized.

Hopefully you won't die for this idea. :-)

Kind regards

    robert