David A. Black <dblack@wobblini.net> wrote:
>
> I think what's happening is that people who've used Ruby for a while
> get used to it, and then they sort of shift their readability
> threshold. In other words, if you've seen this:
>
> a.map {|b| b.meth }
>
> for several years, then even though it looked beautiful and concise
> and transparent to you at first, it will start to look verbose and
> syntactically inefficient. So then you might want to have:
I usually come around to agreeing with you that so-and-so change adds
more line noise than is worth it, but this particular one I've disliked
right from the beginning. It's not just the visual clutter, it's the
conceptual overhead of introducing a new variable merely because ruby
has to attach a method to something. Note the progression from
On Fri, 28 Oct 2005 19:27:03 +0200, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:
Hugh Sasse wrote:
# A factory method
def create_pizza(t=[:pepperoni, :ham] named :toppings, c=[:thin] named :crust_thickness)
imaginate(:pizza_factory).make_me(c,t) # [1]
end
nice short vars for codeing, then # My toppings for today
mt=[:ham, :cheese, :pineapple]
pizza = create_pizza(mt named :toppings)
Looks interesting... I still think this is better, though
class Pizza
def initialize(named toppings, named crust_thickness = :thin) @toppings = toppings @crust_thickness = crust_thickness
end
end
look any better? Not to me. To me it looks worse b/c of what :a and
a::b are.
I admit I haven't read all of the posts in the named parameter threads,
so I apologize if my question is answered there, but why does there
even need to be a new syntax for declaring methods with named
parameters at all? My first thought as to what "adding named
parameters to Ruby" means is that *any* method can be called using
named parameters or not. I.e., given a method:
It would be nice if Array#=== was aliased to Array#include? So that
somearray === someval
would check for membership. You can "cheat" a bit with the case
statement as follows:
a = [1,2,3,4]
b = 3
case b
when *a
puts "match"
else
puts "no match"
end
This works with any object that responds to to_a but of course
requires that an array be constructed instead of a more efficient
lookup into the object that could be done via a
customized === method.
See my recent posting about this (ruby-talk:162999)
···
On Oct 28, 2005, at 1:07 PM, Trans wrote:
Case in point, what's the english equiv of #===. I'd really like to
have one.
No, I do not think Ruby should stagnate and be dead. If 1.8.3 were
the last version, it would not stagnate and be dead, because people
*use* it and do things with it. The fact that, for me, that counts
as non-stagnation does perhaps mean that I am quite conservative
about language change. I don't think the language needs to change,
unless something is truly broken or missing.
I love the current Ruby syntax.
If 2.0 just contained a faster Ruby, and kept the same syntax, I'd be
overjoyed.
I agree. If all Ruby 2.0 brought was a VM I’d be happy. That, and
M17N...and perhaps keyword arguments ;-D,
nikolai
And I'd be happy with just native threads. Nothing else.
I find it interesting that before 1.8 was released, I was frequently
installing the latest 1.7.x because it had some new feature I needed. I
kept that up for a while with 1.9.x just out of habit, but didn't really
need anything that was in 1.9 but not 1.8. I'm very happy with 1.8.2, in
fact.
···
On 10/28/05, David A. Black <dblack@wobblini.net> wrote:
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
I agree with you that many suggestions have arisen, but many of them are
simply a way to think outside the box (I hate myself for using that
phrase, but I can't think of anything better.)
Ruby the Can-Do langauge
I think one of the many great things about Ruby is that each new
addition is carefully considered; does it correspond to the Ruby Way? It
it clear to me that `collection.every.method' does not. Neither do I
think the `->' lambda syntax does.
The { |x| ... } syntax never turned me on about Ruby. In fact, my
first thought what why not do(x) ... end. But it was the *utility* of
blocks that made the difference.
I agree with David in the general points, but for what is worth, I agree with TRANS on this, I always thought {|x|...} was unrubyish, even when I did'nt had a grasp of what rubyish could mean (and probably I still don't)
If you are so bold, I have to chime in again to say that
ary.sort_by :meth
reads a lot better than
ary.sort_by.meth
because we don't do method chaining here.
Sorry, could not resist.
best regards,
Brian
···
On 29/10/05, Trans <transfire@gmail.com> wrote:
Martin DeMello wrote:
> David A. Black <dblack@wobblini.net> wrote:
> >
> > I think what's happening is that people who've used Ruby for a while
> > get used to it, and then they sort of shift their readability
> > threshold. In other words, if you've seen this:
> >
> > a.map {|b| b.meth }
> >
> > for several years, then even though it looked beautiful and concise
> > and transparent to you at first, it will start to look verbose and
> > syntactically inefficient. So then you might want to have:
>
> I usually come around to agreeing with you that so-and-so change adds
> more line noise than is worth it, but this particular one I've disliked
> right from the beginning. It's not just the visual clutter, it's the
> conceptual overhead of introducing a new variable merely because ruby
> has to attach a method to something. Note the progression from
>
> ary.sort {|a,b| a.meth <=> b.meth}
> ary.sort_by {|a| a.meth}
> ary.sort_by :meth
Hehehe, I'm just saying that I think these discussions get out of hand
occasionally.
I do take part in some Ruby Quizzes which I find both fun and useful.
The recent thread about finding non-unique array elements got pretty
long, but in the end we all learned quite a bit. Work and play can
sometimes be combined.
I admit I haven't read all of the posts in the named parameter threads,
so I apologize if my question is answered there, but why does there
even need to be a new syntax for declaring methods with named
parameters at all? My first thought as to what "adding named
parameters to Ruby" means is that *any* method can be called using
named parameters or not. I.e., given a method:
def foo(a, b)
a + b
end
It can be called in any of these ways:
foo(5, 3)
foo(a=5, b=3)
foo(b=3, a=5)
Why can't this be made to work?
Because "a=5" is an expression that returns a value, and is thus allowed as an argument. That would create an ambiguity between "a=5" as an expression whose return value is used as argument and "a=5" as a named argument receiving a value.
Anyway, quite a few people, including myself, don't like the idea of all arguments being optionally named arguments. It obliges method arguments to be part of the method interface, and that should only happen *when the developer explicitly wants it that way.*
I know it's a feature of Python, and maybe it hasn't brought anything bad to it. However, it's one of the reasons why I quit learning the language. It wasn't the only syntax feature I disliked, but it didn't balance things out either.
In my example, the value :really_thick will be assigned to the method's local variable `crust_thickness', and `[:pepperoni, :ham]' to `toppings'. Otherwise, you would have to do the following:
Hehehe, I'm just saying that I think these discussions get out of hand
occasionally.
I think this is nothing to worry about. After all, I'm a big fan of democracy and still think it's better than other forms of government (please don't take the discussion down *that* road too far). But the main point here is that it's everybody's own decision whether he / she participates in these threads. With a little experience you can easily detect those threads and ignore them if you feel like it. And since you're using gmail you don't have to worry about space and or bandwidth either, do you?
I do take part in some Ruby Quizzes which I find both fun and useful.
The recent thread about finding non-unique array elements got pretty
long, but in the end we all learned quite a bit. Work and play can
sometimes be combined.
Definitely.
To sum up: I'm totally with David and I think we should take his statement for what it is: a warning notice, a reminder to maybe more often try to keep some focus but not more - especially not any form of censorship.
And what does that mean and how often do I need it?
regards,
Brian
···
On 29/10/05, Trans <transfire@gmail.com> wrote:
Brian Schröder wrote:
> If you are so bold, I have to chime in again to say that
>
> ary.sort_by :meth
>
> reads a lot better than
>
> ary.sort_by.meth
>
> because we don't do method chaining here.
>
> Sorry, could not resist.
This is definitely superior to chaining methods. For one, because chaining causes the wrong perception that the chain is executed once but in fact a proxy object is created behind the scenes that applies the rest of the chain to every instance. And also the proxy object might be slower than the direct execution of the chain. Just because it's possible it doesn't mean it's better or more readable. My 0.02 EUR...
Kind regards
robert
···
Trans <transfire@gmail.com> wrote:
Brian Schröder wrote:
If you are so bold, I have to chime in again to say that
