Req #9331 [Com]: No operator overloading available

Edit report at https://bugs.php.net/bug.php?id=9331&edit=1 ID: 9331 Comment by: ptheofan at gmail dot com Reported by: jgsmith at tamu dot edu Summary: No operator overloading available Status: Not a bug Type: Feature/Change Request Package: Feature/Change Request Operating System: Irix 6, Solaris 7, OpenBSD 2.8 PHP Version: 4.0.4pl1 Block user comment: N Private report: N New Comment: +1 Besides the obvious advantages (and horrorful disadvantages of bad practices), it could benefit the optimization/performance of the code execution. Previous Comments: ------------------------------------------------------------------------ [2015-10-20 11:08:31] a at ustimen dot co I propose to add this as a module which is disabled by default. Many other standard enabled modules are useless out-of-the box, so we should give to average PHP developers a choice to use or not use this feature. ------------------------------------------------------------------------ [2014-07-15 10:14:57] php-operator-overloading at mandark dot fr +1 ------------------------------------------------------------------------ [2013-08-15 14:59:31] themastersleader at hotmail dot com I so agree with "f3n6s at objectmail dot com" I had many cases that i needed the operator overloading. Saying it will never get into the core. It's even stranger that the DateTime class is "hacked" to overload the equality operators. ------------------------------------------------------------------------ [2012-07-03 15:01:38] ivebeenlinuxed at googlemail dot com I agree, this is a significant feature missing from PHP and this shrugging it off is really just not helpful. I cannot implement function overloads into a PHP script for a production environment if it is not included in the PHP core or default deployment packages. ------------------------------------------------------------------------ [2011-07-28 15:16:28] f3n6s at objectmail dot com Saying "such a feature won't go in PHP's core." Is tantamount to saying "There shall never be operator overloading in PHP" since, if it's not in the core, nobody can use it practically! Fine. Don't put it in the core. Put it on the back of a flying monkey. I don't care. But /enable/ it by default so people can use it. Second- mysterious eyebrow raising followed by "well i dunno.. thre are many problems, what if we want to vardump an array operator overloard object" and whatnot is completely backwards. You have destroyed and forgotten and thrown away everything that was once great about PHP. If such eyebrow raising had occurred when you added __get and __set, and heebee-jeebee about "proper object oriented design", then those would never have made it in. Same for a milion other features that made PHP unique and special, capable of things other languages just /couldn't do/. Third, it's been written! 575 lines of clean, simple, straightforward code sitting there on PECL. Dare-I-say, even /trivial/! And as for the comments of "oh, well, there are side effects we would have to work out..." If I don't want the side effects then I won't use the construct. __toString has /side/effects! As I said, there were things; humble things; that once made PHP great. But around the time that Zend and SPL and the rest of that junk came out, those things became less important, and PHP has incrementally become just like every other langauge out there. In response to this little gem form the "php manual user note system": - Your disdain for PHP and/or its maintainers. Go learn FORTRAN instead. Well heck, why don't we all go use JAVA if we wanna do "proper OOP". I'd much rather do cool things in half the time. /rant ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=9331 -- Edit this bug report at https://bugs.php.net/bug.php?id=9331&edit=1