On Sat, Jan 17, 2015 at 11:33 AM, Todd Ruth <tr...@proposaltech.com> wrote: > On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote: >> >> We are talking about something deprecated since 10 years, about the 1st >> >> major release in a decade, something we will use for the next 12-14 years. >> > >> > >> > That is the point - PHP 4 constructors have NOT been marked as deprecated >> > in >> > the manual, and they produce no warnings at runtime. >> > >> > If they have not been marked as deprecated then you cannot suddenly remove >> > them. >> >> Warning: a long response with code snippets/ >> >> [ Snipped examples of mixing constructor flavors / namespaces ] >> > >> Then there are no warnings of any kind (since PHP 5.3.2), and >> __construct is used as the constructor. The method test is just a >> normal method. >> >> To me this clearly indicates three things: >> >> 1. Having both forms of constructors is bad form (hence the E_STRICT) >> 2. When both are present the new-style __construct is used over the >> old-style PHP 4 constructor, meaning the language prefers >> __constructor. >> 3. Old-style constructors don't exist in namespaces. Notably this >> was a conscious choice as evidenced by behavior that existed in PHP >> 5.3.0 - 5.3.2 where the E_STRICT was emitted like non-namespaced code. >> >> This is the behavior of shipped, stable versions of PHP. I think it's >> a bit illogical to conclude that just because there aren't any >> E_DEPRECATED warnings emitted in PHP 5 that old-style constructors are >> fully supported. >> >> That leaves us realistically with four options: >> >> 1. Bring full support for PHP 4 constructors >> 2. Emit E_DEPRECATED when PHP 4 constructors are used >> 3. Drop support for PHP 4 constructors so they are just normal >> methods, just as they are in namespaces >> 4. Maintain current behavior. >> >> As already mentioned I think as an end result we shouldn't have two >> ways to define constructors. Given that PHP already prefers the >> new-style constructors I've proposed that we work towards dropping the >> old-style, it's just down to a matter of how. > > I've been following these threads for about 10 years and beg that php > internals continues to "live and let live". > There have been many, many threads over the years from what I would call > (with obvious bias) "OO fundamentalists". They seem to be at war with > code that is "bad form". Fortunately, most of their victories to date > have been in the form of adding "E_STRICT"s. There seems to be a > compromise in the community that we won't break people's code, but we'll > let them know when they are using bad form code. I believe that's > reasonable. > Please don't construe the willingness to add E_STRICTs with agreement > that such code should be forcibly eliminated.
According to the PHP.net documentation on E_STRICT(http://php.net/manual/en/migrating5.errorrep.php): > When enabled, messages will be issued to warn you about code usage which is > deprecated or which may not be future-proof. By very definition E_STRICT warns about this kind of thing. They've been there for *more than ten years*. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
