From: Rick DeNatale <rick.denatale@...>
Date: 2006-09-16T04:52:59+09:00
Subject: Re: arbitrary indexes

On 9/15/06, Jason Nordwick <jason@adapt.com> wrote:
> In my original message, I asked for people not to answer "change the
> behavior of [] yourself" beause changing the base semantics of indexing
> is likely to play havoc with the other developers (we have about 5 writing > with the same code) or possibly another package we import (this type of
> collision has already happened once to us on a relatively small project, and > we had to turn off an couple inlined C method because of it).
>
> "Change the base behavior of this builtin" and "write it in C" have
> become the chief dodges of the Ruby community to any substantive
> criticism.

Just because Ruby allows you to change base classes, doesn't mean that
you should.  In most cases, you are right, you shouldn't.

However, what's the alternative in other languages?

And "write it in C" is only opinion held by a few, most performance
problems are amenable to finding better algorithms.

And where's the "substantive criticism" in your question.  As I
understand it you wanted "to find a simpler way than i.map{|x|v[x]}
which seem like an aweful lot of syntax."

So v.values_at(i) was suggested.  Seems like a lot less syntax to me.
BUt your 'criticism' became it wasn't compact enough.  Well if you
want to you can use method_alias so you can say something like:

    v.va i

more compact at the price of clarity, and although you're adding to
Array in order to do this, it's probably fairly safe in this case.

On the other hand, it's probably just better to use the standard
values_at method for the sake of you and your team, might as well
LEARN ruby while you're using it.

> I now have a file I load that includes base extensions to the language that > should probably be supplied by the system, and that files seems to just
> keep growing. Ruby is become less productive of a langauge because of it
> because I spend more time either searching for these functions like
> "values_at", writing extentions to [] or such, and then debugging them
> when the interactions with other parts of the system fail.

This reminds me of the old joke about the guy who goes to the doctor
and says "It hurts when I do this, Doc!", and the doctor says "Don't
do that."

A mature development team would go back through those extensions and
remove/rework them as they learned, the same thing should be said of
our own code, it's called refactoring.  My mother would call it
keeping the house clean.

I'd turn this around and ask if maybe you're preventing yourself from
becoming a productive Ruby programmer by resisting learning the
language. Languages per se aren't productive, it's the combination of
programmer and language.

If Ruby isn't the language for you, then just use something else.
Since the goal of Ruby is to make programmers happy, if some
programmers are happier using another language, that should be fine.

But if you're looking for a language which predicts your every whim, I
suspect that you are going to have to design, implement, and debug it
yourself. <G>

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/