Re: [Zend Engine 2] ZendEngine2/RFCs/002.txt
| From: | Dean Hall | Date: | Sun, 09 Sep 2001 04:20:22 +0000 |
| Subject: | Re: [Zend Engine 2] ZendEngine2/RFCs/002.txt | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-1852@lists.php.net to get a copy of this message | ||
----- Original Message -----
From: "Stig Sæther Bakken" <ssb@alltheweb.com>
To: <engine2@lists.zend.com>; <pear-dev@lists.php.net>
Sent: Saturday, September 08, 2001 06.42am
Subject: [Zend Engine 2] ZendEngine2/RFCs/002.txt
> Introducing namespaces, it would make the most sense to change the
> HTML_Table class to HTML:Table (class Table in the HTML namespace).
> But that means the HTML/Table.php file would define symbols in the
> "HTML" namespace, not "HTML:Table" as you might expect.
My gut feeling is that I don't expect that. I expect the Table class to be
defined in the HTML namespace.
> Okay, we might live with that, but what if you also have some
> functions or constants in HTML/Table.php? Since namespaces are
> per-file, they'd also end up in the HTML namespace, which is
> definitely what you'd be interested in (they could basically clash
> with any other HTML_Something package.
Good point. It might actually be a good idea for the Table class to be in
its own (sub) namespace (i.e., PEAR:HTML:Table).
> I can see four ways of dealing with this:
>
> 1. Allow mid-file namespaces changes that would allow a file to
> contain:
>
> namespace Foo;
> class Bar ...
> namespace Foo:Bar;
> constants ...
>
> 2. Change the entire PEAR class<->file scheme to a class<->namespace
> scheme. This would be pretty ugly, we'd end up with fully
> qualified class names such as "HTML_Table:Table" or "HTML:Table:Table".
I think the 'HTML_Table'-type naming should go the way of the dodo. The
'HTML:Table:Table' naming might make sense -- or rather
'PEAR:HTML:Table:Table'. It's referencing the Table class in the
'PEAR:HTML:Table' namespace.
> 3. Make a namespace "instantiatable" like I suggested a month or two
> ago. This is what Perl/CPAN ended up doing, probably for the same
> reasons I'm losing hair over this. :-)
This might be a good way of doing it if PHP was more Perl-like. As it is,
PHP is much more like C++ or Java in terms of OO syntax. The way Perl makes
namespaces instantiable is way beyond the scope of what PHP can do, I think,
and it would lead to horrible backwards-compatibility and migration
problems.
> 4. <your brilliant idea goes here>
I wouldn't call them brilliant, but here are my ideas:
1)
Emulate Java . . . kind of. Java has a classpath environment variable which
is very akin to PHP's include_path. I suggest using the include_path for
searching for a namespace.
So PEAR's HTML_Table class would be referenced like 'PEAR:HTML:Table' -- the
class, not the namespace. The DB class would be referenced like 'PEAR:DB'.
(I do not suggest that root/super-classes in PEAR be in the global
namespace.)
Basically, then, a namespace is denoted by a directory. If you have a class
in that namespace, you put it inside that directory in a file called
ClassName.phpm (or whatever extension -- just a suggestion to have a special
file extension for modules). Any functions or constants would be in a file
called main.phpm -- and would always be loaded for that namespace.
This has some problems, but with some collaboration, I think the problems
could be ironed out.
Result: $db = new PEAR:DB(...);
2)
Have instantiable namespaces, but not automatically. For a namespace to be
instantiable, it must have a class defined in it of the same name.
Result: $db = new PEAR:DB(...);
--------------------
The problem I'm finding here is that we cannot emulate either Java or Perl
effectively. If we're looking for another language to set the example, I
suggest we look elsewhere, like C++. Automagically loading files, however,
as C++ doesn't do, is where we may need to be creative.
Java allows absolutely nothing to be defined outside of a class. We could
emulate Java except for the fact that PHP allows functions, constants,
variables, and code outside of classes. We could require everything in a
namespace to be in a single file, but this could get nasty and unwieldy.
Perl allows a namespace to be instantiated, provided only that some class
method blesses a variable (usually a hash) and returns a reference to it.
PHP has no notion of blessing anything -- it's gone on for several years now
with no notion of namespaces whatsoever. Adding namespace support to PHP, I
think, will not be easy.
Dean.