* Mark J. Reed <[EMAIL PROTECTED]> [2008-03-19 20:45]: > Maybe it's just 'cause I cut my teeth on BASIC, but + for > string concatenation has always felt pretty natural. Obviously > it won't work in Perl where you are using the operator to > determine how to treat the operands. At first blush I find it > more readily readable than "&" or "||", or even ".".
Personally, after getting thoroughly used to Perl, I always have a vague feeling of unease in languages where I need to use + to concatenate. It makes the meaning of the statement dependent on the types of any variables, which is information that a reader won’t necessarily find in close vicinity of the statement. And that’s exactly what led me to the idea I proposed in the initial mail in this thread – changing the meaning of an operator from one monomorphic operation to another within a lexical scope. > Hopefully, the new meaning is somewhat related to the original > - a sort of operator metonymy - but if the context is > sufficiently different, that's not a requirement. Again, > nobody's going to think you're dividing pathnames. Strongly disagree. If context was sufficient to help the reader, how did operator overloading get such a bad rep in C++? That’s exactly what my proposal was all about: if you’re completely changing the meaning of an operator, the reader should have nearby indication of what is really going on. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
