Re: [VOTE] Userspace operator overloading

Hi! > C++ has a philosophy: "Trust the programmer." [1] PHP is not C or C++. The latter languages are aimed at seasoned programmers who are supposed to know what they're doing (and the non-ending stream of buffer overflows, double-frees and other security issues by now shows us how well that worked, but sometimes we don't have any other choice). PHP is aimed at the beginner, and it's not uncommon for people to write (and/or read) the first code in their life in PHP. That implies some responsibility from the language designer that can not be dismissed by "we trust the programmer, so all the blame is on them if something goes wrong". No, sometimes if the construct is inviting abuse, it shouldn't be there to be abused. > that many are not amused by the overloading of ">>" and "<<" to > mean > input and output, the larger issue is that using such stream operators > and function overloading provides an elegant and extensible way of One person sees "elegant", another sees "wtf is this jumble of cryptic symbols and why I need to spend 3 months figuring out how it works?" Again, for a C/C++ program - especially for C++ with is choke-full of unobvious magic - it is normal, if you're C++ programmer, you're expected to deal with it. PHP is not that language. In PHP tradition, write-only code is not a good thing, however "elegant" it seemed to whoever constructed it. > I know PHP is not C++, but other languages has been mentioned in this > context, and another core tenet of the C++ language is that it's more > important to provide useful abstractions, rather than banning anything > that may be misused. That's why we have different languages. Because for C++ it's important to give access to maximum things with maximum efficiency, and if you can't deal with the heat, you shouldn't play in the kitchen. For PHP, it's important to be understandable and not introduce too much of an unobvious magic. > Let's face it, you could make "add()" _subtract_ the numbers, or do > strange things, just as well as you could do with a function overloading > "+". I don't see what this is supposed to prove. Yes, you can screw up in many ways. Is it an argument to add one more way to screw up, because since you already could screw up in other ways? If that's an argument, it is not one that looks particularly convincing to me. > Personally, I find it a greater gain in terms of code clarity to be able > to write e.g.: > > $result = $a + $b * $c + $d; > > rather than: > > $result = $a->add($b->multiply($c))->add($d); The cases where you need to add and multiply something that aren't actually numbers, but behave like numbers, are very rare. TBH, how many of PHP programmers occupy their days by designing - or using - quaternion-handling libraries? Not a lot, I think. More frequent case would be "why I don't make my BankAccount class support + operation because doing $account += $number is much more 'elegant' than $account->add($number)". And this is exactly wrong thing to do. Short term, you saved yourself some typing and gained some cool points. Long term, you've set up future yourself and your team for failure because there's unobvious magic going on and "+" doesn't mean anymore what everybody would assume it means, because bank accounts aren't numbers, so "+" has different semantics, but it's not obvious what exactly that semantics is. > Quick: Is the second one exactly identical to the first one? Nobody cares because you shouldn't use the first one with not numbers (unless you implement quaternions, in which case you're the tiny minority which shouldn't be considered when talking about generic rule). > Would you catch that in code? Yes, because I'd never use operator overloading for such objects. > There's a reason mathematicians have invented a set of symbols: It makes > it easier to comprehend code using it, than if you only use function > notation. Code in PHP is not a mathematical equation, however. And if you think mathematical equations are the example of something easy to read and understand for a beginner, we obviously have very different experience with how equations look like. -- Stas Malyshev smalyshev@gmail.com