Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49132
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:from:date
         :x-google-sender-auth:message-id:subject:to:cc:content-type;
        b=XXf9/vX9M0z910aI43Ej9q3K1BYoQrs+K6Ypy+zbfyUhMTdDeAUtRK9KnLyMQe5rnJ
         Jry522mJ7NzDVMMzMQ2WpIya6a6uC9j8R5eU4c91L5agmtHNmYY+tajEZjxz14QXK/qO
         QXAiR7NccrarRFc/83sY14atnRPYkSq8WPEWY=
MIME-Version: 1.0
Sender: chx1975@gmail.com
In-Reply-To: <AANLkTik7T6ee7Bd=J4DvVzpC_LJppqgWZ_7xj-S=L2=r@mail.gmail.com>
References: <AANLkTik4JFIs6y1jSK8_6OAbTdoikvwEWwoIKNH3QFrb@mail.gmail.com> 
	<730E72B7-B2C3-4FF9-8138-F04659ECDB56@php.net> <AANLkTin8eaBcb7ekj-ZjF7GVXbrcn8ZTEyVS-zW6AsOf@mail.gmail.com> 
	<4C4950B2.40805@thelounge.net> <AANLkTi=fs_fEzFC4zdq4VVfkhzWQYpcEenSmUf+2QoOh@mail.gmail.com> 
	<AANLkTik7T6ee7Bd=J4DvVzpC_LJppqgWZ_7xj-S=L2=r@mail.gmail.com>
Date: Fri, 23 Jul 2010 11:06:01 -0700
Message-ID: <AANLkTinqE8Kc186Ch0O6RYE3v=mvU37tdLMMZH9NPvMv@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Remove variable function and method calls
From: karoly@negyesi.net (Karoly Negyesi)

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