On 20.05.2008 21:24, Robert D. wrote:
examples, what do you prefer? IMHO, the former syntax attracts
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:
ZEIT ONLINE | Lesen Sie zeit.de mit Werbung oder im PUR-Abo. Sie haben die Wahl.)
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