The only issue with using \ is the fact that this is the escape
character. If you are using PHP to create classes (collapsing complex
classes into simpler ones, implementing a fake AOP), you have to
remember to escape the escape. It just seems odd to re-use a symbol
like this. A new symbol is better. IIHMY, I would use # and remove #
from comments. # looks like a grid which can be thought of as a
compartmentalisation process; i.e. grouping things together in their
own little space - a perfect concept to explain namespaces. We already
have singleline and block comments with // and /* ... */. Not really
sure of the need of #. Of course, this would be an evern bigger BC.
Even my own code uses #.
The triple colon (:::) is OK, but what happens during a mistype. Is
there a possibility that :: and ::: COULD be used interchangably (an
extreme example), producing working code?
On 14/11/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Jessie,
Tuesday, November 14, 2006, 5:00:42 AM, you wrote:
> What does everyone else think? Are functions/constants inside namespaces
> really that critical?
> Anyways, I just thought of a possible solution to the namespace
> separator issue, and if it's doable, then the double colon (::) can even
> be used and no conflicts would occur. It seems the biggest problem with
> handling namespaces is determining if a symbol is a class or namespace
> at compile-time. I am no expert in flex/bison, but I was thinking that a
> state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will
> return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on
> whether the symbol is known to be a class or namespace. The user will
> add either a "using" or "import" statement before the use of the symbol,
> and this will allow the parser to know what that symbol is in the
> compilation phase. As an example:
> // BEGIN CODE
> using namespace PEAR::File;
> $items = File::Find::glob( '!.*\.php$!', $dir, 'perl' );
> // END CODE
> The first statement will add an entry into a hashtable (used during
> compilation) indicating that "PEAR", "PEAR::File", and "File" are
> namespaces ("File" will be imported in the current file only). When
> "File::Find::glob" is parsed, the compiler already knows that "File" is
> a namespace, so "Find" must be a class inside that namespace, and "glob"
> must be a static method. With this, functions and constants can easily
> be added inside namespaces, as the "using" or "import" statement will
> indicate to the parser which portion of the qualified name is a namespace.
> Is this feasible in flex/bison? Let me know if anything needs clarification.
Short: no
Long: Please stop confusion here. We will get namespace innwith either ":::"
or "\" depending on who is going to implement it and what otherissues that
one will encounter. Later we may decide based on that implementation whether
it might be possible to use a different seperator. Btw, ifI wereto implement
namespacesupport today i would go with "\" as that is easier to translate to
a directory/file name in an __autoload function. While yesturday people
nearly convinced me (during the last conferences) that ":::" is closer to
the class/member seperator "::".
best regards
marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
