Hello Richard,
as though what you say is true the rules are different inside {} inside "".
best regards
marcus
Wednesday, November 15, 2006, 9:39:48 AM, you wrote:
> Would $foo = "{mynamespace\tables_class::myconst}";
> \t in "" is a tab. \m in "" is nothing but \m
> Thats the sort of thing I'm worried about.
> On 14/11/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>> 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
>>
>>
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
