Re: namespaces?

From: Date: Thu, 12 Jul 2001 22:45:24 +0000
Subject: Re: namespaces?
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-691@lists.php.net to get a copy of this message
At 10:49 PM 7/12/2001 +0200, Stig Bakken wrote:
Andi and Zeev, Remember when we discussed namespaces at the PDM? I'd like to pick up that thread. The PEAR community wants namespaces. :) You might argue that classes provide this, but in the end they don't. Classes can not encapsulate constants or classes. What most people want seems to be what Java has: 1. A user-selectable symbol table (ala "package nnn" in Java/C++) 2. Symbol aliasing, ala "import" in Java/Python) 3. Language constructs that load code from a given name space (ala "use" in Perl). This was attempted once for PHP, but it ended up as something else and finally "gave birth" to the *_once functions as a kind of middle-ground. These are features that I and the rest of the PEAR community really want to see in Zend 2.0 in order to make PEAR able to grow without much pain.
Stig, I'll be happy to discuss this and see what exactly needs to be done and what can be done. I think adding static members to classes (which we plan to do) is a first step. However, I understand you guys want more than that. I don't have any good answers right now because of PHP's loosely typed and loosely linked nature (such as run-time includes and eval's). One thing to keep in mind is that PHP is not a strictly typed compiled language. Therefore, things which can be done in Java and C++ can't necessarily be done in a good way in PHP. The fact that PHP is such a loosely typed scripting language has its many pluses especially when it comes to development time and ease of use, on the other hand mechanisms which compiled languages can supply, such as type checking and polymorphic functions is something which can't be done in PHP. However, as Python and Perl have managed to do something in the area of packages (from what you say) I think it's worthwhile to have a discussion on what can and can't be done. Hopefully we can get some good ideas rolling. But keep in mind that we'll really have to find a solution which fits the current PHP model and which doesn't cause a serious performance penalty. Can we have this discussion on the engine2 mailing list as I'm not subscribed to pear-dev and it's a bit hard for me to handle yet another mailing list (I'm already on too many). As I have very little experience with Perl & Python it's probably best if you guys roll out some ideas of what you have in mind (whilst trying to keep the PHP limitations in mind) and we can try and see if something cool can be done. Andi

« previous php.pear.dev (#691) next »