From: Conrad Schneiker <schneiker@...>
Date: 2002-01-19T03:18:54+09:00
Subject: Re: a wishlist for ruby 2.0

"Daniel Berger" <djberg96@hotmail.com> wrote:

[...]

> * Keyword/Named arguments (of course).

Yes.

> I actually *prefer* the commas -
> easier on the eyes, IMO.

I don't understand how this relates to your preeding sentence.

> * Eliminate separate methods for "modify receiver in place" with some
other
> mechanism.  Either modify the receiver based on calling context (void ==
> modify, rvalue == don't modify), or provide a special generic method that
> modifies the receiver.

I've already said too much about the simpler solution involving consistent !
naming in the style (so I'm told) of Scheme. Oops. :-)

> * Some sort of Inline mechanism that allows for multiple languages to be
> coded within Ruby based on a common syntax, analogous to the Inline.pm
> module in Perl.

I thought someone was already planning to do this. IIRC, the Inline.pm
author offered to help someone do this (and, IIRC, conversely).

> * Elimination of alias methods.  Pick one method name and use only one.

This bugs a number of other people, who don't want to have to learn multiple
names in order to read otherwise equivalent code written by others. I'd like
to see this done as well (even though I'm at fault for previously
encouraging an alias or two).

I'd also vote for removal of the Perl $<char> globals and use the equivalent
$<English_names> that Ruby already provides (and eliminate the terser
English aliases of longer English names), but with some _moderate_
abbreviations in some cases, e.g.
INPUT_ ==> IN_,
OUTPUT_ ==> OUT_,
SEPARATOR_ ==> SEP_,
_NUMBER ==> _NUM,
_POSITION ==> POS
_RECORD ==>_REC.
This would pretty much eliminate residual cryptic Perl "line noise".

However changing and/or deprecating features (and providing swichable
warning support, etc.) is a big hassle (although the Python world apparently
has some conventions that a great many people find tolerable). While no
automated code conversion support tools can presently deal with overly
creative uses of eval(whatever), hopefully such things will be tolerably
rare problems.

Conrad