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@xxxxxxxxxxxxxx> wrote:
2008/5/20 Guoliang Cao <caogl@xxxxxxxxxxx>:
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
.

Relevant Pages

  • Re: Method as first class member
    ... On Tue, May 20, 2008 at 4:55 PM, Robert Klemme ... I believe we get shorter, more intuitive code with this kind of syntax, ... metaprogrammers and DSL writers it would be a *convenient* feature. ... IMHO making Ruby a functional language does not ...
    (comp.lang.ruby)
  • Re: The Eiffel Compiler tecomp version 0.24 released
    ... I'm sorry but reading a.b does not read as a check to me. ... It is in the same position as a called feature and, ... To avoid overloading at the syntax ... Since doing so might entail loosing focus or even incite language ...
    (comp.lang.eiffel)
  • Re: bash script to convert date seconds back to date format..
    ... Robert F. Chapman wrote: ... following syntax. ... Im not sure when the feature was added, but I remember seeing it used ...
    (Fedora)
  • Re: Code Guidelines
    ... The language lets you do a lot of things. ... is the feature which was specially designed. ... possible to dynamically augment any other user-defined objects (but ... functionality directly on object – ...
    (comp.lang.javascript)
  • Re: Relative merits of Lisp-1 vs. Lisp-2?
    ... If reading data that might be ill-formed, defining your language to ... to dismiss my concern about this issue as irrelevant and unimportant, ... This argument would apply to *any* proposed new feature, ... incompatibilities were simply the result of someone doing something ...
    (comp.lang.lisp)