Re: Re: PHP 5.1 (Or How to break tousands of apps out there)
| From: | Ron Korving | 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