Remove variable function and method calls

16 years ago by Karoly Negyesi — view source — reply

unread

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

16 years ago by Davey Shafik — view source — reply

unread

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

16 years ago by Karoly Negyesi — view source — reply

unread

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.

16 years ago by Joel Perras — view source — reply

unread

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

16 years ago by Karoly Negyesi — view source — reply

unread

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

16 years ago by Evert Pot — view source — reply

unread

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

16 years ago by Stas Malyshev — view source — reply

unread

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

16 years ago by Marco Tabini — view source — reply

unread

So you do not consider it utterly confusing that

No. I know kung-fu.

16 years ago by Kalle Sommer Nielsen — view source — reply

unread

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
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

16 years ago by Reindl Harald — view source — reply

unread

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

16 years ago by mathieu.suen — view source — reply

unread

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

16 years ago by Karoly Negyesi — view source — reply

unread

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

16 years ago by Reindl Harald — view source — reply

unread

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

16 years ago by John LeSueur — view source — reply

unread

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 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

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

16 years ago by Ionut G. Stan — view source — reply

unread

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

16 years ago by Karoly Negyesi — view source — reply

unread

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...

16 years ago by Reindl Harald — view source — reply

unread

Am 23.07.2010 01:36, schrieb Karoly Negyesi:

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...

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?

16 years ago by Karoly Negyesi — view source — reply

unread

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

16 years ago by Stas Malyshev — view source — reply

unread

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

16 years ago by Karoly Negyesi — view source — reply

unread

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.

16 years ago by Stas Malyshev — view source — reply

unread

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

16 years ago by Daniel Egeberg — view source — reply

unread

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.

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

16 years ago by Jille Timmermans — view source — reply

unread

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

Remove variable function and method calls View as Markdown

Short answer: No. Long answer: No way.

This is plain false. PHP does care for BC a lot.