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. Smylers
