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. The
latter is syntax sugar. It is important, but not at the price of making
code harder to read or language slower to work.
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.
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, so you need to jump trhough various hoops to make it work in
non-typed way, while preserving it's typedness benefits. PHP works
differently - you don't have benefits and need no hoops.
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.
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. Even if you could - how many operator+'s
you are willing to write? For all type combinations? Or what is supposed
to happen if + called for type combination that you don't have an operator
for?
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. 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.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
