Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61883
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain meetme.com designates 74.125.149.141 as permitted sender)
MIME-Version: 1.0
Sender: wfitch@meetme.com
In-Reply-To: <1343675518.12438.84.camel@inspiron>
References: <op.wh9sbkyzidpuyk@damnation>
	<1343675518.12438.84.camel@inspiron>
Date: Mon, 30 Jul 2012 15:26:27 -0400
Message-ID: <CAArmra0jO2cR_f6Dj5vQKagNfDo9TFq7Bi9vfGLyWg3=-zo0EA@mail.gmail.com>
To: Todd Ruth <truth@proposaltech.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec55245ecc411f904c61109c8
Subject: Re: [PHP-DEV] [RFC] Remove calls with incompatible Context
From: willfitch@php.net (Will Fitch)

--bcaec55245ecc411f904c61109c8
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jul 30, 2012 at 3:11 PM, Todd Ruth <truth@proposaltech.com> wrote:

> 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.
> >
> > --
> > Gustavo Lopes
>
> 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 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.


Software evolution at this level will always have some aches and pains for
someone.  This is a feature that has been discouraged (E_STRICT) for a very
long time, and, as pointed out in the RFC, is around only to be compatible
with PHP 4.  This should've been nixed with the death of PHP 4 IMO.  If we
waited around for everyone to update their codebase before
deprecating/removing features, it would never happen.  The point of
deprecation is to give a final warning that a feature is going to be
removed in a future release.  This should be your company's indication to
make the necessary changes.

That said, the length of deprecation is up in the air.  I'm not sure that
removing in the release immediately after deprecation is the right route,
but deprecating this in the next release *should* happen.


> Off-topic, but to show a potentially higher priority...
> If you want to get rid of class related WTF, please put
> get_class() back to the way it used to be.  Right now, calling
> get_class() with a variable that is null is the same as calling
> get_class with no arguments.  I can imagine why that might be
> convenient for the implementation, but it is terribly confusing.
>
> Thanks for listening.
>
> - Todd
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--bcaec55245ecc411f904c61109c8--