Hello Richard,
The "#" is needed for CLI mode - thus we won't remove it. In fact we
will not do anything that would cause BC problems. Also there is no
escaping issue with "\". If there is than it is outside of PHP. In
other words:
- "\" is the only single character reachable from 'western' keyboards
- $foo = "{mynamespace\myclass::myconst}"; // will be possible without
escaping
Please people read the archives before posting here, we have discussed
all this long enough.
Tuesday, November 14, 2006, 9:36:10 AM, you wrote:
> 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
>>
>>
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
