RE: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)
| From: | Bob Silva | Date: | Fri, 25 Nov 2005 20:33:45 +0000 |
| Subject: | RE: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there) | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-20441@lists.php.net to get a copy of this message | ||
That follows my sentiment, I think namespace implementation should be
fast-tracked before a PHP 6 release to give developers time to modify/adjust
their code to work with core object classes.
Personally, I think PHP shouldn't have any classes within the global scope,
but have them beneath something akin to the System class in Java and C#.
Then standardize this System namespace (SPL is a good start) as a place to
develop object interfaces to core functionality like the Date class.
Then when someone wants to use PHP's date class they can just import it.
import System\Date;
Now PEAR is let off the hook, as am I and many other developers who have
existing classes that will conflict with any core objects in the future.
Bob Silva
> -----Original Message-----
> From: Marcus Boerger [mailto:helly@php.net]
> Sent: Friday, November 25, 2005 11:28 AM
> To: Christian Schneider
> Cc: Ilia Alshanetsky; PHP Developers Mailing List
> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out
> there)
>
> Hello Christian,
>
> here again namespaces would be perfect. Given a lib that doesn't prefic
> you'd simply d:
>
> namespace LibNameHere { reqire "some_lib_include"; }
>
> and be done...wohooo :-)
>
> regards
> marcus
>
> Friday, November 25, 2005, 2:14:10 PM, you wrote:
>
> > Ilia Alshanetsky wrote:
> >> Defining classes/function with generic names will always be a problem
> as
> >> they may end up conflicting with same constructs from other libraries
> or
> >> PHP itself.
>
> > Sure. But that doesn't change the fact that a class named date is
> > *known* to cause conflicts. And that the core has a higher
> > responsibility than any extension/library/package IMHO.
>
> >> To design future proof code projects for the most part prefix all their
> >> functions/classes to prevent naming conflicts.
>
> > Had a quick glance at Gallery2 because it was lying around and they
> > don't consistently prefix things. Most classes are prefixed but not all
> > of them. I'm inclined to believe that's the case for most popular
> > packages, let alone everything else.
>
> >> It makes little sense to have a class called curl_curl, when it comes
> to
> >> functions the coding standard applied and all functions have a prefix.
>
> > That's why I wrote "... (at least when a common name like date is
> > used)". While Curl is unique enough (although I'd rather have a longer
> > name for the sake of a uniform naming scheme) the name date will
> > *definitely* be causing problems. We all agree on that I think.
>
> > The question is only if you shift the responsibility to PHP developers
> > (a mere dozen people could decide to change it) or to PHP users
> > (thousands, not even aware of the issue).
>
> > Signing out of this thread with a plea for pragmatism,
> > - Chris
>
>
>
>
> Best regards,
> Marcus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php