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
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
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.
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.
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.
--
--
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
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
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
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
withcall_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
So you do not consider it utterly confusing that
No. I know kung-fu.
2010/7/23 Karoly Negyesi karoly@negyesi.net:
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
withcall_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
Am 23.07.2010 02:29, schrieb Karoly Negyesi:
You can call classname::$foo() and even $obj->$foo() with
call_user_func()
should we get rid of those too?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
Would you like to know what is really confusing?
mysql_escape_string
mysql_real_escape_stringSo 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
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
First:
A personally answer is NOT "the list"
Am 23.07.2010 17:27, schrieb Karoly Negyesi:
Idiotic point of view, really there is no brain behind
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
On Fri, Jul 23, 2010 at 9:40 AM, Reindl Harald h.reindl@thelounge.netwrote:
First:
A personally answer is NOT "the list"Am 23.07.2010 17:27, schrieb Karoly Negyesi:
Idiotic point of view, really there is no brain behind
Really? so we are now down to personal attacks.
Sorry but if you do not understand the first answer i have
to make it clearNow listen. Every
PHP version breaks backwards compatibilityBut NEVER without any reason
Nobody, bever in no project has to make incompatible
changes just for funI 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 okNow, 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 warnings122 production installations with error_reporting
E_ALLincludingE_STRICTIf 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_ALLI 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 confusedI 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
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
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