[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zend-engine2
Subject:    ZendEngine2/RFCs/002.txt
From:       ssb () alltheweb ! com (Stig =?iso-8859-1?q?S=E6ther?= Bakken)
Date:       2001-09-08 11:42:14
[Download RAW message or body]

[Cross-posted between engine2 and pear-dev since this message mostly
touches PEAR topics.]

There are a few comments in RFC 002 (lines starting with "#") that I'd
like to get opinions on (pear-dev: check out ZendEngine2 from
cvs.zend.com, see RFCs/002.txt).

I expect some controversy around the "Name:Space:blah" syntax, so just
shoot me with it right now :-)

Also, I have not included anything about loading namespaces yet.  The
reason is that as I was writing that section, I suddenly remembered
that I never decided on how it should be done with respect to PEAR, so
some ideas around that would be welcome.  Here's my problem:

Today, PEAR basically maps between files and classes, you get the
HTML_Table class when you include "HTML/Table.php".

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.

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.

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".

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. :-)

4. <your brilliant idea goes here>

Help! :-)

 - Stig

-- 
  Stig Sæther Bakken <ssb@alltheweb.com>
  Fast Search & Transfer ASA, Trondheim, Norway

[prev in list] [next in list] [prev in thread] [next in thread]