Re: namespaces?

As an FYI, I think that if PHP followed perl's guidance here for classes/name spaces, it might work out well. Perl has 2 constructs for this. 1) Use: This construct is used by the programs that want to USE a specific class. In the process of the use statement, a name space for the package is setup. This is defined by #2. Use statements look something like this: use CGI::FastTemplate; What this does is it goes out and finds the file CGI/FastTemplate.pm and includes the contents of the file (ala the include/require statement in PHP) into the current source code. 2) Package: This construct is used inside each class definition and defines the actual namespace for the class (class and package in perl are used interchangeably as perl created classes out of it's package mechanism.). IE In the FastTemplate file, the first line would be: Package CGI::FastTemplate; This line is what actually defines the name space. From now on, ALL variables inside this file (FYI, name spaces are file scoped) will implicitly be in the CGI::FastTemplate name space. IE the FULL name of the variable $loop would REALLY be $CGI::FastTemplate::loop. And if I wanted to refer to this variable OUTSIDE of the class, I would have to use that syntax. Now perl isn't truly OOP. IE you can't have private/protected members ace you can in C++ and company. But for the most part, this works quite well! :) -- Jeff Stuart jstuart@neo.rr.com "Andi Gutmans" <andi@zend.com> wrote in message news:5.0.2.1.2.20010713013552.037ea4d8@mail.zend.com... > 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 >