Re: RFC 159 (v1) True Polymorphic Objects
[email protected] (Jonathan Scott Duff)
| Newsgroups | perl.perl6.language.objects |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Aug 25, 2000 at 03:23:25PM -0000, Perl6 RFC Librarian wrote: > Operator Overloading > ------------------------------------------------- > PLUS Called in + context > MINUS Called in - context > TIMES Called in * context > DIVIDED Called in / context > MODULUS Called in % context How about ye olde ADD, SUB, MUL, DIV, and MOD? > Others proposed an alternative set of names for these functions, such as > "OP_*" and "OP_-". However, I strongly disagree with these names. First, > they're not English words or phrases, so are bad for humans. Second, > they're not legal \w+ names, which is something we should not circumvent > with special cases. Third, they're not consistent with already-existing > Perl functions like C<FETCH> and C<STORE>. Finally, there is actually a > good amount of ambiguity. For example, does "OP_*" refer to a unary or > binary * context? With the word "TIMES" there is no such ambiguity. I agree. OP_*, etc. are very bad names. > =head1 MIGRATION > > This introduces new functionality, however p52p6 would have to catch any > subs defined with the names listed above and warn the user that this sub > name is now reserved for Perl. I continue to think that stealing names from the programmer is a bad thing. That's what RFC59 is all about. If we're going to use allcaps subroutines to mean something special to perl I think we should make it an error for the programmer to use them. Or as RFC59 suggests, make the perl-special subroutines *really* special so that users can't accidently change the behaviour of their program by defining a subroutine called CREATE (or whatever). -Scott -- Jonathan Scott Duff [email protected]