Re: [ruby-cvs:18323] ruby: * eval.c (splat_value): use "to_splat" instead of "to_ary" to

Yukihiro Matsumoto <[e-mail]> writes:
> Hi,
>
> In message "Re: [ruby-cvs:18323] ruby: * eval.c (splat_value): use "to_splat" instead of "to_ary" to"
>     on Sun, 8 Oct 2006 14:05:30 +0900, Mathieu Bouchard <[e-mail]> writes:
>
> |> Could you explain how to_splat be bad?
> |
> |It makes one more thing to remember about Ruby 1.9, which is a bigger 
> |language than Ruby 1.8, which is a bigger language than Ruby 1.6. You 
> |don't have to compete with Perl 6, and you don't even have to compare Ruby 
> |2 to Perl 6 thinking how much simpler Ruby 2 is.
>
> Every language grows in more recent version, as Ruby does, and PL/I
> did, until it grows too much to collapse into a black hole by its own
> gravity.  It's kind a like destiny.  Otherwise the language will die.

Just to add the voice of my group, we appreciate things getting better
over time, and we don't mind updating and retesting code if we decide
to take advantage of improvements.

> For people who don't like growing languages, the current 1.8 was
> forked off from the development line (or perhaps, 1.9 was forked off
> from the stable line).  They will be happy using "stable" Ruby.

Some people just don't get this for some reason.  Maybe they were
damaged by the transition from Perl 4 to Perl 5 where that community
decided to shout at anyone who asked a question about Perl 4 until
they upgraded.  There are also factions who seem to want only their
favorite changes and not anyone elses'.

We have no problem tying our code to a specific version of Ruby.  In
fact, each of our major projects has its own private installation of
Ruby and libraries (in something like /project/production/ruby), even
when multiple projects are using the same Ruby version.  We think it's
silly to do anything else, even if Ruby was guaranteed to be 100%
backward-compatible.  We then have a 'global' Ruby installation where
we feel free to upgrade Ruby (and more importantly extensions/gems)
with impunity.  I suppose in some way we anticipated the Rails freeze
tasks.  We freeze Ruby too.

Steve