Hey Levi,
> On 15 Jan 2015, at 17:16, Levi Morrison <[email protected]> wrote:
>
> On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds <[email protected]> wrote:
>>
>> A better solution, IMO, might be simply to add a deprecation notice. This would make it
>> obvious during development if you’ve accidentally defined a PHP4 constructor, and would encourage
>> migration away from them, but wouldn’t prevent existing code from working.
>
> Possibly. The reality of my position is that I am unhappy about our
> current constructor situation. Having __construct and only
> half-heartedly supporting old-style constructors for the next several
> years (maybe ten?) does not sound good at all.
I agree, it doesn’t. Unfortunately, I’m not sure if we have much choice here.
> Removing one of the constructors is a nicer end product than fully
> supporting both, in my opinion, which is why I proposed dropping it. I
> was hoping that a deprecation notice in 5.7 would be sufficient along
> with other standard migration tools and documentation, but since we
> have decided to not release 5.7 perhaps a deprecation would be better.
>
> At the same time I'm not thrilled about the amount of deprecation
> notices that could be generated if this is really as common as people
> seem to make it. I generally don't see these older constructors, but
> it seems when people have them they have *a lot* of them.
Yeah, I’m wondering about that. I imagine that a single request would probably result in a massive
spew of E_DEPRECATEDs, and that’s not good. :/
> I was okay
> with this in a theoretical 5.7 release to ease migration because it
> had a fixed lifespan of one release cycle but in version 7 it will
> stay for the duration of all PHP 7 releases.
>
> What do you guys think?
I wonder if we could hopefully get rid of them for PHP 8 or something, since it’s deprecated…
but then, if we don’t get rid of them now, we might never.
I’m not sure, really.
--
Andrea Faulds
http://ajf.me/