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
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 a
Marcus Boerger 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 reachab
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' keyboa
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 bett
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 (::
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 pro
Hi Marcus,
Can you please clarify where the conflicts will occur if only classes
are allowed in namespaces?
Best regards,
Jessie Hernandez
Marcus Boerger wrote:
Hello Jessie,
we already have consts in our classes, if you look close then you will see
that the table does not conatain 'na
Hello Jessie,
we already have consts in our classes, if you look close then you will see
that the table does not conatain 'namespace:const' but only 'namespace:class'
and still there are conflicts already.
best regards
marcus
Sunday, November 12, 2006, 1:48:22 AM, you wrote:
> Hi Marcus,
> A
Hi!
If the namespace-approach only covers classes it is implemented
half-heartedly, IMO. I see a lot of "classes" that are just really
collections of static functions, that's what namespaces should cover,
too. And disallowing constants only so that : works is a bad tradeoff...
Regards,
Stefan
--
Marcus Boerger wrote:
Hello Jessie,
[snip]
Maybe this new discussion gave one hint. Aliases could be solved with a
flag. Just copy the classwith a new name into the classlist again and flagit
as copy. Maybe the original class gets a list of the copies of the copies a
pointer to the original b
Hi Marcus,
As I said, I wanted to only enable classes inside namespaces, and NOT
allow functions or constants. class::const would stay the same, so there
are no conflicts.
Marcus Boerger wrote:
Hello Jessie,
sorry to say this but look at the following, keeping in mind that the
whitespace
Hello Jessie,
sorry to say this but look at the following, keeping in mind that the
whitespace is optional.
$x = $foo ? class:const : $var// 1, 0
$x = $foo ? class:const : const; // 1, 0
$x = $foo ? class:const : class:const;
13 matches
Mail list logo
