> TS>>As someone said, "Syntactic sugar matters, or we'd all be writing assembly > TS>>code." :) > > Someone was wrong. There are syntax constructs that allow to reduce > complexity of the code, and there are constructs that make the code have > the same complexity but look prettier to the eyes of the writer.
It depends on how you define "complexity". Are the following two lines equally complex to you: 1) $result=$c1.multiply($c2).divide($c1.add($c2)); 2) $result=($c1 * $c2) / ($c1 + $c2); They sure aren't to me. Moreover, they are not the same: operator overloading enable you to use infix notation, whereas functions use prefix, only. > The > latter is syntax sugar. It is important, but not at the price of making > code harder to read If it makes the code harder to read, it's not much of "syntactic sugar", is it? I can't see why operator overloading should make it harder to read. The only thing I can think of is that, given that there's no type declarations in PHP, it may be hard to know, looking at a line, what the type of the variable is. However, in a properly written program, the actual type may not be that important. Take for example: $sum = $money1 + $money2; Whether or not the variables are built-ins or from a money/currency class, should matter little to your understanding of this code. > or language slower to work. Why would it become slower. As you say, the notation is essentially "syntactic sugar" for a function call, and should be equally fast. > TS>>Besides, it's not "just" syntactic sugar: See my other posts in this thread, > TS>>but briefly, they enable "generic code" - code that may be used by both > TS>>built-in and user-defined types, without knowing or caring which is which. > > I don't see how using $a + 1 is better than using $a->add(1) in this > regard. What if you want to add two variables? > TS>>That is indeed powerful, and most of the advances in later years in C++ has > TS>>come in the area of generic programming (where templates are used for this, > TS>>since types are checked at compile-time). > > C++ is typed Statically typed, yes. >, so you need to jump trhough various hoops to make it work in > non-typed way, while preserving it's typedness benefits. Yes, if you want to use C++ in a typeless/dynamically typed way, you need to use things like templates, or a variant type. However, since those are available, you get the benefits of something similar to type inference, and also static type checking. > PHP works differently - you don't have benefits and need no hoops. You don't have benefits of what? (Should "don't" have been omitted?) > TS>>This is no more confusing than "increment_and_return($i)", where you may > TS>>also need to look at the function definition. I find the first version much > TS>>clearer, though. > > Well, I guess it's the matter of personal taste. For me, the second is > the clear winner - you can name function after what it actually does and > not hope that everybody knows ++ makes an iterator go to the next element. Oh, well. Programming by guesswork is always hard. A point with programming languages is that once you've learned them, and their abstractions, it makes it easier for you to program. Operator overloading is no different. > TS>>Both would work if we allow operator overloading on free functions. But that > > It can't be done without making PHP strict-typed - you coldn't really > distinguish which function is to be called, and you couldn't distinguish > between functions with same name. Yes, you'd need function overloading (we already have type hints, which could be used for the overload resolution). > Even if you could - how many operator+'s > you are willing to write? For all type combinations? That depends on what you want. I can't see how this question is different from "How many member functions (like add()) are you willing to write?"? > Or what is supposed > to happen if + called for type combination that you don't have an operator > for? An error, like today. > TS>>Operator (and function) overloading is not an OO feature. However, it's > TS>>often found in OO languages, and complements OO well. It's a different kind > TS>>of polymorphism. > > It's no kind of polymorphism at all. Yes, overloading is a form of polymorphism. Depending on the type of the arguments, different functions are called. This is analogous to inheritance-based polymorphism (virtual functions). See http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.pdf for a good treatment of the various kinds of polymorphisms there are (even if the article is rather mathematical/technical). > It just an infix form of writing a > method instead of prefix form, with additional problem that it is confused > with plain old arithmetics. I see no value at all in this except for "cool > toy" value - which is not enough to add such a serious change in the > language. I beg to differ. Operator overloading allows you to write what essentially are domain-specific languages (DSLs) in the language itself. For example Boost.Spirit allows you to write a parser, by expressing the rules in near-EBNF form, directly in the code! (http://www.boost.org/libs/spirit/doc/introduction.html) Do _that_ in PHP. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
