# Remove variable function and method calls - Thread: https://externals.io/message/49109 - Original archive: https://news-web.php.net/php.internals/49109 - Started by Karoly Negyesi on 2010-07-22T22:54:29+00:00 - Messages: 23 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #49109 — Karoly Negyesi — 2010-07-22T22:54:29+00:00 URL: https://externals.io/message/49109#49109 Hi, Given that call_user_func exists I would recommend to remove $foo() from PHP Next. Observe the "logic" in the following examples: $foo(); new $foo(); classname::$foo; classname::$foo(); There is a word for this and that word is madness. The simplest is to nuke $foo(). `call_user_func()` is a perfect replacement. Regards Karoly Negyesi --- ## #49111 — Karoly Negyesi — 2010-07-22T23:36:44+00:00 URL: https://externals.io/message/49109#49111 > public function __get($subclass) > { >  $include_file = CONTENTLOUNGE_BASEDIR . 'api_' . $subclass . '.php'; >  $class_name   = 'cl_' . $subclass; >  $this->$subclass = new $class_name(); >  return $this->$subclass; > } And this code contains no variable function call. You mixed it up with a variable class name perhaps? That's why I want to nuke it... --- ## #49112 — Reindl Harald — 2010-07-22T23:47:45+00:00 URL: https://externals.io/message/49109#49112 · In reply to: #49111 Am 23.07.2010 01:36, schrieb Karoly Negyesi: > > […] > > And this code contains no variable function call. You mixed it up with > a variable class name perhaps? That's why I want to nuke it... You said "Remove variable function and method calls" There are sure thousands of nice implementations you like to kill because you do not like such code - So do not write such code but stop to try kill things that are making php strong in so many cases! I do not waste time to search throw-away-code which was only used one time to convert / import wahtever some htings with quick&dirty-implementation where it does not matter if this is beautiful, it has to run once and save time instead of doing something manually And yes there are sue cases to swithc an internal method-call by some parameters - the question is not if this is good on all places where such things are used - the question is why will you kill it? --- ## #49113 — Davey Shafik — 2010-07-22T23:51:10+00:00 URL: https://externals.io/message/49109#49113 · In reply to: #49109 You can call classname::$foo() and even $obj->$foo() with `call_user_func()`, should we get rid of those too? I grant you that variable function calls are sometimes confusing, lambda functions are a better way to do it perhaps, but just because something can be abused, doesn't mean it should be removed, unless it's impeding further innovation (a la namespaced old style constructors). - Davey > Hi, > > Given that call_user_func exists I would recommend to remove $foo() > from PHP Next. > > Observe the "logic" in the following examples: > > $foo(); > new $foo(); > classname::$foo; > classname::$foo(); > > There is a word for this and that word is madness. > > The simplest is to nuke $foo(). `call_user_func()` is a perfect replacement. > > Regards > > Karoly Negyesi --- ## #49114 — Karoly Negyesi — 2010-07-23T00:29:32+00:00 URL: https://externals.io/message/49109#49114 · In reply to: #49113 > You can call classname::$foo() and even $obj->$foo() with `call_user_func()`, should we get rid of those too? Absolutely not. > I grant you that variable function calls are sometimes confusing, lambda functions are a better way to do it perhaps, but just because something can be abused, doesn't mean it should be removed, unless it's impeding further innovation (a la namespaced old style constructors). It's not abusing it's the horribly confusing syntax. --- ## #49115 — Joel Perras — 2010-07-23T00:42:25+00:00 URL: https://externals.io/message/49109#49115 · In reply to: #49114 What's confusing about it? Each expression means something very different and distinct. I use $foo(), new $foo(), classname::$foo, classname::$foo(), $bar::$foo, $bar::$foo(), etc. on a regular basis, and it can make for some very elegant, concise and readable code. Moreover, this really isn't something you can just remove from the language. There's already a fair bit of code (including my own) out in the wild that makes use of this syntax. -j. > > > […] > > Absolutely not. > > > […] > > It's not abusing it's the horribly confusing syntax. > > -- > > > > -- I do know everything, just not all at once. It's a virtual memory problem. You should follow me on Twitter: http://twitter.com/jperras --- ## #49116 — Karoly Negyesi — 2010-07-23T00:49:39+00:00 URL: https://externals.io/message/49109#49116 · In reply to: #49115 > What's confusing about it? Each expression means something very > different and distinct. > > I use $foo(), new $foo(), classname::$foo, classname::$foo(), > $bar::$foo, $bar::$foo(), etc. on a regular basis, and it can make for > some very elegant, concise and readable code. So you do not consider it utterly confusing that classname::$foo classname::$foo() mean two completely different things? The first reads a property the second reads a local variable. Any time you need to backtrack when you the source code because something you tackled on after changes the meaning of the code completely is considered horribly confusing in my opinion. And then it's utterly nontrivial what new $foo() *should* do. Should it call $foo() and instantiate the class name found in the return value or should instantiate the class found in $foo? If you nuke variable function calls and method calls and replace them with `call_user_func()` then these go away. Regards NK --- ## #49117 — Evert Pot — 2010-07-23T00:55:44+00:00 URL: https://externals.io/message/49109#49117 · In reply to: #49116 > > So you do not consider it utterly confusing that > > classname::$foo > classname::$foo() > > mean two completely different things? The first reads a property the > second reads a local variable. Any time you need to backtrack when you > the source code because something you tackled on after changes the > meaning of the code completely is considered horribly confusing in my > opinion. I don't disagree it can be confusing and inconsistent. However, I would bet there's no way you'll see backwards compatibility broken for purity sake. Therefore, this is a bit futile. Evert --- ## #49118 — Ionut G. Stan — 2010-07-23T01:05:57+00:00 URL: https://externals.io/message/49109#49118 · In reply to: #49109 > Hi, > > Given that call_user_func exists I would recommend to remove $foo() > from PHP Next. > > Observe the "logic" in the following examples: > > $foo(); > new $foo(); > classname::$foo; > classname::$foo(); How about: $lambda = function () {}; $lambda(); What should happen in this case? -- Ionuț G. Stan | http://igstan.ro --- ## #49119 — Stas Malyshev — 2010-07-23T01:09:41+00:00 URL: https://externals.io/message/49109#49119 · In reply to: #49116 Hi! > classname::$foo > classname::$foo() > > mean two completely different things? The first reads a property the And classname::foo and classname::foo() means two different things too. So what? Language has its rules, learn them. It's not that hard. > If you nuke variable function calls and method calls and replace them > with `call_user_func()` then these go away. Short answer: No. Long answer: No way. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #49120 — Marco Tabini — 2010-07-23T01:31:49+00:00 URL: https://externals.io/message/49109#49120 · In reply to: #49116 > So you do not consider it utterly confusing that No. I know kung-fu. --- ## #49122 — Kalle Sommer Nielsen — 2010-07-23T04:04:56+00:00 URL: https://externals.io/message/49109#49122 · In reply to: #49116 2010/7/23 Karoly Negyesi : > > > […] > > So you do not consider it utterly confusing that > > classname::$foo > classname::$foo() > > mean two completely different things? The first reads a property the > second reads a local variable. Any time you need to backtrack when you > the source code because something you tackled on after changes the > meaning of the code completely is considered horribly confusing in my > opinion. > > And then it's utterly nontrivial what > > new $foo() > > *should* do. Should it call $foo() and instantiate the class name > found in the return value or should instantiate the class found in > $foo? > > If you nuke variable function calls and method calls and replace them > with `call_user_func()` then these go away. > I do not see whats wrong with the variable function call syntax at all, most other languages like JS have similar concepts, even C. But unlike those, PHP does not use function pointers and is loosely typed so there is "no" distinct callback type. Variable function calls are very handy for various tasks that have a really dynamic internal API, removing it from the language is a huge BC break, along with all the other statements in this threads. So no its not going to be removed. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #49124 — Reindl Harald — 2010-07-23T08:20:02+00:00 URL: https://externals.io/message/49109#49124 · In reply to: #49114 Am 23.07.2010 02:29, schrieb Karoly Negyesi: > > > […] > > Absolutely not. Idiotic point of view, really there is no brain behind If you want a really clear syntax you must remove all of this cases because it would be inconsistent do it the way you wish and the result would be confusing for every other than you > It's not abusing it's the horribly confusing syntax. So damned do not use it but stop such braindead ideas like break backward compatibility just for fun - Please seach another toy instead try to damage programming languages. WHAT let you believe anything you saidin this topic makes sense? _______________________________________ Would you like to know what is really confusing? mysql_escape_string mysql_real_escape_string So if you have nothing to do try to cleanup this hint: "mysql_real_escape_string" never should have existed this way and should be dprecated for some relaeses until finally "mysql_escape_string" does what the user expects --- ## #49128 — mathieu.suen — 2010-07-23T09:56:33+00:00 URL: https://externals.io/message/49109#49128 · In reply to: #49124 > Would you like to know what is really confusing? > mysql_escape_string > mysql_real_escape_string > > So if you have nothing to do try to cleanup this > hint: "mysql_real_escape_string" never should have existed this way > and should be dprecated for some relaeses until finally > "mysql_escape_string" does what the user expects > > Is there a [wiki] page to put all of what need to be clean? -- Mathieu Suen --- ## #49129 — Karoly Negyesi — 2010-07-23T15:27:06+00:00 URL: https://externals.io/message/49109#49129 · In reply to: #49124 > Idiotic point of view, really there is no brain behind Really? so we are now down to personal attacks. Now listen. *Every* PHP version breaks backwards compatibility and we (I am one of the lead Drupal developers) struggle with making Drupal compatible with the subtle, often undocumented changes. It was quite long ago but didnt PHP 4.4 break array functions not to accept NULLs instead of empty arrays? Now, PHP 5.3 breaks things so big time it really should have been PHP 6.0 because this sets up an expectation that everything that worked with 5.2 works with 5.3 because it's not a major change. Still: we cope as best as we can. Now, I have pointed out calmly why this syntax is confusing by giving some examples and my problem is not that it's confusing to me. You would need to go far beyond what PHP can do to confuse me, believe me. In fact, I have amended documentation to make sure others understand it. I have pointed out why it's confusing which apparently noone read and have pointed out that there is an equivalent replacement which again noone read because someone asked whether I want to remove call_user_func too which is the very alternative I have pointed out. I have refrained from writing to this mailing list for years. It's crystal clear again that feedback is not welcome, my emails are not read and now I am personally attacked so I will stop here and revert to lurking. You guys can continue breaking the language and make our life hell. I tried. Kind regards Karoly Negyesi --- ## #49130 — Reindl Harald — 2010-07-23T15:40:44+00:00 URL: https://externals.io/message/49109#49130 · In reply to: #49129 First: A personally answer is NOT "the list" Am 23.07.2010 17:27, schrieb Karoly Negyesi: > > […] > > Really? so we are now down to personal attacks. Sorry but if you do not understand the first answer i have to make it clear > Now listen. *Every* > PHP version breaks backwards compatibility But NEVER without any reason Nobody, bever in no project has to make incompatible changes just for fun > I am one of the lead Drupal developers no comment > It was quite long ago but > didnt PHP 4.4 break array functions not to accept NULLs instead > of empty arrays? If this was a problem the code is crap ARRAY-functions are expecting arrays, if the do not loud cry by other input does not mean the input is ok > Now, PHP 5.3 breaks things so big time it really should > have been PHP 6.0 because this sets up an expectation that everything > that worked with 5.2 works with 5.3 because it's not a major change. > Still: we cope as best as we can. What does 5.3 break? Because you application is not well designed and you have troubles you want a incomaptible change to break other applications? Our core project has 250.000 LOC and get it running with 5.3 needed only 6 changes to get aways some warnings 122 production installations with error_reporting `E_ALL` including `E_STRICT` If 5.3 breaks things that you would like to call it 6.0 think about your code as some other projects should do which are writing thousands of warnings in dhe log with E_STRICT, E_DEPRECATED, `E_ALL` > I have pointed out why it's confusing which apparently noone read > and have pointed out that there is an equivalent replacement which > again noone read because someone asked whether I want to remove > call_user_func too which is the very alternative I have pointed out. Does not matter If you will remove everything that can confuse anybody you have to remove nearly all things which are powerful but this is a bad idea because you will every time have a user with missing skills which is confused > I have refrained from writing to this mailing list for years. It's > crystal clear again that feedback is not welcome, my emails are not > read and now I am personally attacked so I will stop here and revert > to lurking. You guys can continue breaking the language and make our > life hell. I tried. stop to whine! It is not "the list" if you get a personally answer for breandead wishes they have only the reason to break others projects because yours is broken with 5.3 and you will see die other ones too --- ## #49131 — John LeSueur — 2010-07-23T16:09:06+00:00 URL: https://externals.io/message/49109#49131 · In reply to: #49130 On Fri, Jul 23, 2010 at 9:40 AM, Reindl Harald wrote: > First: > A personally answer is NOT "the list" > > Am 23.07.2010 17:27, schrieb Karoly Negyesi: > > […] > > Sorry but if you do not understand the first answer i have > to make it clear > > > […] > > But NEVER without any reason > > Nobody, bever in no project has to make incompatible > changes just for fun > > > […] > > no comment > > > […] > > If this was a problem the code is crap > ARRAY-functions are expecting arrays, if the do not > loud cry by other input does not mean the input is ok > > > […] > > What does 5.3 break? > Because you application is not well designed and you have > troubles you want a incomaptible change to break other > applications? > > Our core project has 250.000 LOC and get it running with 5.3 > needed only 6 changes to get aways some warnings > > 122 production installations with error_reporting `E_ALL` including `E_STRICT` > > If 5.3 breaks things that you would like to call it 6.0 > think about your code as some other projects should do > which are writing thousands of warnings in dhe log with > E_STRICT, E_DEPRECATED, `E_ALL` > > > […] > > Does not matter > If you will remove everything that can confuse anybody you > have to remove nearly all things which are powerful but this > is a bad idea because you will every time have a user with missing > skills which is confused > > > […] > > stop to whine! > > It is not "the list" if you get a personally answer for > breandead wishes they have only the reason to break others > projects because yours is broken with 5.3 and you will > see die other ones too > > Reindl is correct in one thing: The tone of his emails is not representative of this list. I don't think your suggestion is "braindead", but I also don't think it's something PHP should do. It's obvious you're not worried about developers working on the core of drupal, but about the developers further downstream, that you have no control over, yet their bugs are reported to you. It sounds like the only case you wish to change is $foo(). "new $foo()" and "classname::$bar()" would be left alone. However, there are rules defining the behavior of all the cases you have cited, and they've been in use for quite some time. There's a lot of code out there that uses it. There are plenty of useful things in PHP that can be misused or misunderstood, but the fact that a feature can be misused or misunderstood is not a good enough reason to remove it. The fact that new(ish) functionality now can replace the old functionality adds to your argument, but is outweighed by the sheer weight of code out there that uses the older syntax. John --- ## #49132 — Karoly Negyesi — 2010-07-23T18:06:01+00:00 URL: https://externals.io/message/49109#49132 Hm, a touch of civility. OK let me retry then. So what I tried to say is this: If you treat ::$ as a single construct in your mind then you will get classname::$foo() wrong. Of course the rule is that classname::.....() is a method call but it's less evident by just looking at the code. I have suggested that removing the $foo() construct completely, $foo(), $bar->$foo(), bar::$foo() all would solve this and although it breaks backwards compatibility, there is a perfect replacement by using `call_user_func()` instead. I have implied that PHP does not care about backwards compatibility breaking and this especially will be true for the next release. This was supported by my experience working with various PHP versions over many years. I can of course understand that code cleanup needs to make certain things go away. If noone maintains ereg, it needs to be deprecated. Fine. It now throws an E_DEPRECATE error which is also completely new. Once again I understand the reasons for introducing E_DEPRECATE but it does not change the nature of the beast. Some code cleanup made necessary to not accept `NULL` as an empty array which might be more debatable because `NULL` is casted happily to zero and empty string as necessary without a word and so why it's not to empty array. But, that's not the point and it's way too late by many years anyways. The point is that PHP does break backwards compatibility going against the public perception. This same false belief is seemingly held by some PHP developers too -- didn't Adam just say that such changes need to be fought hard and supported by strong arguments? I want to see strong arguments for not casting NULLs into empty arrays :) I could report breakage but I sincerely doubt it would change anything because they are made for good. Once again: the hell is not the changes, it's the expectation that old code runs on new PHP unmodified. As for Drupal, very briefly, I only included it to show that I use PHP and a lot and there is more than me here. If by 'no comment' you mean Drupal sucks, then I merrily agree with you. Two things to note: one, believe me when I say you won't find anyone alive who knows more about the shortcomings of Drupal architecture and implementation than me. By this point, I am probably responsible for more than I want to admit. Two, "All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005." http://buytaert.net/drupal-sucks-less Regards Karoly Negyesi --- ## #49133 — Stas Malyshev — 2010-07-23T18:36:10+00:00 URL: https://externals.io/message/49109#49133 · In reply to: #49132 Hi! > If you treat ::$ as a single construct in your mind then you will get > classname::$foo() wrong. Of course the rule is that classname::.....() is a > method call but it's less evident by just looking at the code. It's really not that hard. It'd take you 1/100 of the time you are wasting discussing it to learn it, and that's counting only your time. > I have suggested that removing the $foo() construct completely, $foo(), > $bar->$foo(), bar::$foo() all would solve this and although it breaks backwards > compatibility, there is a perfect replacement by using `call_user_func()` instead. That will not happen. There's tons of downsides and not one single upside to it. > I have implied that PHP does not care about backwards compatibility breaking and > this especially will be true for the next release. This was supported by my > experience working with various PHP versions over many years. This is plain false. PHP does care for BC a lot. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #49134 — Karoly Negyesi — 2010-07-23T19:34:44+00:00 URL: https://externals.io/message/49109#49134 · In reply to: #49133 > This is plain false. PHP does care for BC a lot. OK. I will try to test PHP to help you guys in this. I know there is documentation but it often misses crucial subtle points and there is not a lot of education of the public to set expectations. In other words, how can I help best? If I try to run Drupal with a daily build then I will chase all the build bugs constantly. If I tell at an alpha / beta stage then it'll be too late. How best to address this? We have an automated testbot, it's not perfect but it helped a lot. I wonder whether it'd be possible to get it set up to run a daily build...? I will see what I can do. --- ## #49135 — Stas Malyshev — 2010-07-23T19:38:54+00:00 URL: https://externals.io/message/49109#49135 · In reply to: #49134 Hi! > In other words, how can I help best? If I try to run Drupal with a > daily build then I will chase all the build bugs constantly. If I tell That'd be great. Giving special attention to RCs would also help - it's much better to catch something before the release than people starting to scream when they upgrade after the release. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #49136 — Daniel Egeberg — 2010-07-23T19:52:30+00:00 URL: https://externals.io/message/49109#49136 · In reply to: #49134 > > […] > > OK. I will try to test PHP to help you guys in this. I know there is > documentation but it often misses crucial subtle points and there is > not a lot of education of the public to set expectations. If the documentation is missing information about BC breaks, please file a doc bug at http://bugs.php.net. If nobody is aware that it is lacking, naturally it won't be improved. -- Daniel Egeberg --- ## #49137 — Jille Timmermans — 2010-07-24T12:34:25+00:00 URL: https://externals.io/message/49109#49137 · In reply to: #49132 > I want to see strong arguments for not casting NULLs > into empty arrays:) All simple types (non object/arrays) getting cast to an array will become array($x) -- Jille