Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61885
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "internals@lists.php.net" <internals@lists.php.net>, "Todd Ruth"
 <truth@proposaltech.com>
References: <op.wh9sbkyzidpuyk@damnation> <1343675518.12438.84.camel@inspiron>
Date: Mon, 30 Jul 2012 22:32:17 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.wh90n3xvidpuyk@damnation>
In-Reply-To: <1343675518.12438.84.camel@inspiron>
User-Agent: Opera Mail/12.50 (Linux)
Subject: Re: [PHP-DEV] [RFC] Remove calls with incompatible Context
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

Em Mon, 30 Jul 2012 21:11:58 +0200, Todd Ruth <truth@proposaltech.com>  
escreveu:

> On Mon, 2012-07-30 at 19:31 +0200, Gustavo Lopes wrote:
>> https://wiki.php.net/rfc/incompat_ctx
>>
>> An RFC for deprecating and removing $this from incompatible context.
>>
>> Comments are welcome.
>>
>
> I'm just a user, but I'd like to beg that the feature not be
> removed, at least not without having an ini setting for at least
> a couple of years.  As the RFC states, "This feature can, however,
> be used  to implement trait-like behavior, and I'm sure someone
> somewhere did such a thing."  I know in our company's code, such
> uses were frequent.  I believe they are still common.  Refactoring
> often doesn't fit the schedule.  I doubt we're unusual in allowing
> classes to do more than they should instead of separating code
> off into a trait or making other high level changes.  Note that
> traits have only been available since March 1, 2012 (php 5.4.0).

I don't doubt that you're not 'unusual in allowing classes to do more than  
they should instead of separating code off into a trait or making other  
high level changes'. I DO doubt, however, that this particular form of  
class bloating is usual or "not unusual". However, it will be impossible  
to collect reliable data on this.

> I don't think axing register globals is very relevant.  Perhaps after
> traits have been available for several years the comparison would
> be better.  With register globals, a good alternative (the $_
> variables) have been around for many years.  With traits, a good
> alternative has been around for a few months.  I think the point
> of mentioning register globals is just to say "We've made huge
> BC breaks before."  That doesn't make it less painful.

1. I don't think how long traits have been around particularly relevant  
here. The relevant question, IMO, is whether an alternative exists. And if  
you're upgrading to a version where call-with-incompatible-context does  
not exist, traits will definitely be an option. At most, it's a point for  
the minority of code that must run in multiple versions, but

2. I don't even agree with the premise. By the time this is removed,  
traits will have been around for quite some time. Plus,

3. There are other low-cost alternatives, namely the obvious one: pass the  
object via an extra parameter instead of operating on $this directly and  
unconditionally. This is really easy to do.

4. Maybe register_globals was not the best example, as you have very easy  
workarounds. But consider the removal of call-time pass by reference  
(deprecated in 5.3 -- if I'm not mistaken -- and removed in 5.4). It's a  
change that does require significant refactoring (not to mention the  
awkwardness of having to use call_user_func_array() to pass by reference  
to __call methods), and it had certainly a much wider use than this.

-- 
Gustavo Lopes