Re: Re: PHP 5.1 (Or How to break tousands of apps out there)

From: Date: Fri, 25 Nov 2005 15:28:53 +0000
Subject: Re: Re: PHP 5.1 (Or How to break tousands of apps out there)
References: 1 2 3 4 5 6 7 8 9 10 11  Groups: php.internals 
Request: Send a blank email to internals+get-20412@lists.php.net to get a copy of this message
> On 11/25/05, Ilia Alshanetsky <ilia@prohost.org> wrote: > > Does this include anytime a new function/class is added we need to make > > a prominent notice about since it reserves some name space? > Yes of course, especially if it's such an obvious name like "date". I disagree strongly. Date is not just a class. I consider it a type, and honestly, if you had your own "Date" class, yes, I do call that naïve. For that same reason I never named by database abstraction class 'DB' for example. PHP goes first when it comes to naming. I know many people disagree, but as far as I'm concerned, the SPL classes don't need a prefix either. Seriously, if you as a developer had your own developed date class called "Date", you just weren't being smart about it. > How am I supposed to know what class names PHP decides to capture > tomorrow? Think logically, and prefix your own "core" classes. > > So, assuming your old applications are totally future proof is naive. > > Well, that's exactly what my customers expect from the software we > develop for them. And btw, maybe it's part of what "enterprise-ready" > is about. I admit that 100% future proofness can never be achieved. > But every break of it it should be carefully considered. And I'm > pretty sure that in the end, companies will go for the platform that > offers the best future proofness of their applications. I think if you look hard there are plenty of examples where enterprise systems were not BC after an upgrade. I disagree with the way this was handled at the last minute, but I don't disagree at all with there being a Date class from PHP5.1. Just inform your users well before they upgrade. Ron

« previous php.internals (#20412) next »