> From: "Stanislav Malyshev" <[EMAIL PROTECTED]> > TS>>across, given what what operator overloading is about). As I've pointed out > TS>>in other postings in this thread, operator overloading is about much more > TS>>than "just" "syntactic sugar". In C++, for example, it enables important > > I think you did not succeed in proving this point. You keep bringing > examples of how useful it is in C++ - which can be interesting to debate, > but is entirely irrelevant to PHP, since PHP is different from C++ on many > levels and tasks that are solved with operators in C++ often even not > exist in PHP (like "smart pointers", etc.). I still fail to see how it can > be really useful - in terms of making something that was very hard to do > before easy to do now - beyond they syntax sugar value.
It's a little hard to bring examples of PHP usage of it, since it doesn't exist there, and therefore we have no experience with it. However, I saw someone post a patch about it, enabling overloaded operators in PHP. > TS>>things such as function objects (being able to pass an object to a function, > TS>>for example, and have it behave as a function, enabling functional > TS>>programming, as well). This is not possible (possibly without jumping > TS>>through major hoops) in PHP. > > Surely it is. Via __call, for example, which is no worse than operator(). > Yes, you could not write it the same syntax as C++ - so what? An advantage of function objects in C++ is that they can be used where functions are expected. Nevertheless, there are some features that can be used to get something similar, such as create_function(): > TS>>However, I see from this and other threads, that there's not much chance of > TS>>evolution of PHP to support more "advanced" features (which are common in > > There's a lot of chance for PHP to evolve, but if you mean by it that any > feature that you might like would be in without scrutiny - yes, there's > little chance for that. By all means, I'm all for scrutiny. :) That's why I bring it up, to possibly stimulate some discussion about it, and, yes, scrutiny. I may learn at least as much from this as anyone else. Simply put, I'd like to know what the arguments for and against are, so that, yes, they may be scrutinised. > TS>>other scripting languages, as mentioned). It seems basic OO support is about > TS>>the only thing the PHP community can handle when it comes to expressiveness > TS>>in the language. Oh, well. > > It means you probably won't see in PHP every feature that your favorite > other language has. So what? Your favorite other language probably doesn't > have all the features of PHP. The new features for PHP should be checked > if they are good for PHP and can be implemented consistently and > efficiently in PHP. True. I see what I wrote above was rather harsh. I guess I in a way hoped that someone would tell me I'm wrong. :) And that the PHP community _is_ interested in improvements in the language (any improvements, these are just some possibilities), and that possibly what I suggest is not what is found to be most interesting, but feature xyz may be, or library x. That would have been fine. I'm here to learn, too. So, ok, I acknowledge that the community _is_ interested in improvements in the language, and therefore take back the paragraph you quote above (and any statements like it). Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
