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. If there were a fully automated tool to bring code into compliance, I would feel a lot better about such changes, but even then, many of us would be applying that tool to third-party code that has been lying around for a decade untouched, and that's scary. I suppose my opinion on these things is formed by my life experience with these issues and since I don't doubt we all mean well, I guess the OO purists probably are approaching this from different life experiences. Here is where I'm coming from: I've been on my current project for over 10 years. We have always had a _very_ small software department. The code was originally developed in php4 style using using objects, but not following the purist OO conventions. We now have hundreds of thousands of lines of php. We've accumulated reliance on many libraries that were written in a variety of styles and generally we're just glad they work. I'm sure there is no active development on many (perhaps most) of them. To this day, we still don't use namespaces or exceptions. We still follow our conventions for prefixing everything to avoid name collisions. We don't have the resources to make major changes without clear benefits to our users. (For the record, when we do find an issue with php, we dig in and try to find a fix and submit it. We've fixed a couple of things. I know it is negligible compared to what most of the folks reading this do.) I don't know how common our situation is, but I'm sure there are others out there. In the global cost/benefit analysis I don't see that the benefits of purifying OO outweigh the costs. Thanks for listening! - Todd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
