Darren Duncan writes:

> At 6:26 AM +0200 9/19/06, Damian Conway wrote:
> > ... *if* we're going to change it from "grep", we ought to change it
> > to "filter".
> I agree.  So "filter" is now my preference for a new name, and if 
> "grep" is kept, then that can be an alias for it;

No: no aliases.  Perl does not have a tradition of these, and overall
aliases tend to add to confusion -- with the result that everybody ends
up having to learn both (or all) names anyway.  And I'm pretty sure
Larry has previously spoken out against aliases.

MySQL's SQL dialect has a few synonyms.  On numerous occasions I've seen
SQL that I didn't think I understood only to discover I knew a different
name for the same thing, or _vice versa_.

use English provides lots of aliases in Perl 5, but note how rarely they
are used in practice.  Even if somebody chose to use English in all her
code she would still have to learn the punctuation variable names to
read others' code, get help from fora, and so on.

And I can honestly say that when reading Damian's 'Perl Best Practices'
when I saw a reference to C<$EVAL_ERROR> I first of all stopped to see
where it had been declared before realizing it was just another name for
the variable I use every day as C<$@>.

> "filter" should be the canonical name for most documentation, though.

That's one of the problems with aliases: if the docs generally use
C<filter> then when a reader encounters code using C<grep> for the first
time he will be more puzzled than if either name had been used
consistently through out.

And you can be sure that most existing Perl 5 coders who are used to
C<grep> would continue to use that name in Perl 6, regardless of what
the docs say.

I do not think renaming C<grep> to C<filter> is a terrible idea, but if
it's being done then it should be done properly, not half-heartedly with
an alias.


Reply via email to