From: Robert Klemme <shortcutter@...>
Date: 2008-05-21T06:50:06+09:00
Subject: Re: Method as first class member

On 20.05.2008 21:24, Robert Dober wrote:
> 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

I definitively think that #call should be retained - simply because 
method objects support it right now (along with #[]) and lambdas do it 
as well.  This makes for good duck typing and makes learning and code 
migration easier.

> 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 would have thought that with metaprogramming these places are rare. 
You typically do not run around and have 50 places in a framework that 
need this.  I'd estimate that in reality there would be only so few 
places - which is logical since metaprogramming usually adds some 
generic feature (just think about how #method_missing is implemented 
only once per interface or class).

> 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
> :(

Yep.

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

Ha!  I tend to get motivation from simplification.  I believe less is 
more.  (btw, some engineers seem to feel in a similar way: 
http://www.zeit.de/2008/21/Autobilligmacher?page=all)

> 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 ;)

That's for sure - good, old European democracy! ;-)

> "Perfect" however is very personal and may vary with time and needs,
> we are surely dreaming a little bit, I have to admit.

That's my main criticism of the term: perfect according to what 
standards?  The "perfect" language would make *all* implementation tasks 
easy, wouldn't it?  But then it would probably contain a standard 
library with solutions for everything.  And then there is the question 
whether making one thing work good will leave others unchanged - my 
intuition tells me that usually optimizing for one feature will 
sacrifice others.  In the real world you always pay a price.

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

We'll see.  I know that I will like the new regexp engine (apart from 
its name which I always keep forgetting maybe). :-)

>> --
>> 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:)"

LOL - thank you!

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

A wise man.  And apparently also a friend of simplification - less is 
more. :-)

Good night

	robert