On Tue, May 20, 2008 at 4:55 PM, Robert Klemme
<shortcutter / googlemail.com> wrote:
> 2008/5/20 Guoliang Cao <caogl / verizon.net>:
>> Robert Klemme wrote:
>
>>> With these questions I always ask myself what do we gain by such a
>>> change?  All changes have some effort attached, some more and some less.
>>>   But it's not worthwhile if the effort outweighs the benefits.  What do
>>> you think are the benefits of this change?  Why should we do it?
>>
>> I believe we get shorter, more intuitive code with this kind of syntax,
>> and partial invocation can help DRY in a lot of cases. Compare below
>> examples, what do you prefer? IMHO, the former syntax attracts
>> programmers to use, the latter is like, do this if you have to(this may
>> not be a bad thing though)
>>
>> "foo"->length
>> "foo".method :length
>
> How often is this used?
Far too rarely I believe, there was a recent tread in which David
Black suggested the :: syntax for method retrieval and . for a method
call
e.g.
o.m(42) the same as
o::m.call(42)
although there was a different syntax for call discussed too but I
honestly do not remember - I was voting for .call so my memory is
biased ;).
I believe that we would see this kind of application quite often

some_method_needing_a_block &o::m
instead of
some_method_needing_a_block { |o| o.m }

Anyway your conservative POV is also very understandable but for
metaprogrammers and DSL writers it would be a *convenient* feature.
I do not daresay if this is reason enough, maybe somebody should take
the bull by the horns and write an RCR to get some voting, alas there
is no voting feature right now, only replys to the RCR on ruby::core
:(

f I rarely see this so I would say, don' t
> bother.  Also, sometimes it can be helpful to be more verbose to
> clarify that something special is happening there.  Also, having a
> rusty C and C++ background I would expect the first syntax to actually
> execute the method and not return a meta data object.
>
> Partial specialization might be a different story but I did not have
> use for that either.  IMHO making Ruby a functional language does not
> work too well.  And actually you *can* have partial specialization
> with lambdas.

Well I would like to have the feature (because I am greedy) but I do
not see usecases, IIRC Facets has something like this, Functors, but I
am not 100% sure.
>
>> I do agree changes require efforts and also add learning burden to
>> users, language designers/implementers have to be very careful with any
>> change to the language. However, most programmers have a dream - a
>> perfect language. Even it may not become true, we are closer than ever.
I guess perfection can only reached asymptotically, meaning huger
efforts for less improvement the closer one gets, but this is a very
private theory of mine - or did I steal it from Relativity? ;)
>> Do you agree?
Yes, pretty much, even if this makes a mess ( one Robert agrees the
other not, but Roberts are organized democratically ;)
"Perfect" however is very personal and may vary with time and needs,
we are surely dreaming a little bit, I have to admit.
>
> No.  I for my part do not dream of a perfect language because I do not
> believe something like that is possible.  Also, I do not believe that
> your proposed change would be an improvement worthwhile considering.
> I prefer to use Ruby the way it is vs. worrying too much about
> improvements.
Sure enough, but you risk not to like some of the changes in 1.9 so
maybe a little bit of soft lobbying for features one likes seems to be
in order.
> --
> use.inject do |as, often| as.you_can - without end
BTW a thing I wanted to say about your sig for a long time now: "I'd
loved to have this idea before you did:)"
Cheers
Robert


---
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein