2008/9/29 Jordi Boggiano <[EMAIL PROTECTED]>
> On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning <[EMAIL PROTECTED]> wrote:
> > +1, I second this completely
> >
> > From someone who *was* using namespaces developing against the 5.3
> branch,
> > this is going to happen sooner or later. I found that :: just causes to
> many
> > questions when used in namespaces. Using :: or -> just for the sake of
> > reusing existing tokens is just wrong. I'm in favor of # if it can be
> worked
> > out.
>
> +1 as well, but I must say # is not right, it is a very black/filled
> character, as in it doesn't visually#separate#words#that#well. Using
> the dot would be really nice, but I guess it would break with
> something like this : "concat".foo.bar()."baz" so it's not an option.
>
> Using a single colon might work out ? foo:bar:class::staticFunc()
> sounds good to me, but maybe I missed something.
>
> I also had the idea of using the underscore, even though I guess we
> can't go through with this as people _might_ have used double
> underscores in their class names, I guess it would work out quite well
> with single underscores, for example :
>
> class Foo_Bar {
> public static function callMe()
> }
> Foo_Bar::callMe();
>
> ..would be read as class Bar in namespace Foo, but it would be
> transparent to everyone since if you use something with a fully
> qualified name you don't need to "use" them, right ?
>
> Anyway it's just a couple ideas, but please stop holding on to that
> double colon.
>
> --
> Jordi
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I agree with you totally that :: makes too much trouble - people are trying
to fix all issues for a few month's now and every time it results in "we cut
$something then it works!" and of course developers as myself start to shout
that we don't need namespaces half implemented, because they are useless
when.
I took part in discussion in two threads by this time:
here: solving the namespace conflict issues between function/static method
class constant/ns constant
AND
here: true namespaces, yet another point of view
Firstly I also proposed . as a separator, but it has issues with constants:
<?php
define('CONST', 'hello ');
class Test {
static function print() {
return 'world!';
}
}
echo CONST.Test::print();
?>
That now results in "hello world!". So if CONST is a namespace and we have
constant named the same - a problem occures. Well, that can be worked around
- we can check for name collision and give an error, but I think people will
shout at that as bad, wy we can't have namespace and constant named equaly?
Well, I would live with that perfectly, but something tells me developers
will be against this.
Other problem is resolution.
MYNAMESPACE.Test::print() - what is it? A constant named MYNAMESPACE or a
namespace itself?
As I understand, during compile time that isn't a problem to resolve whether
it is constant or namespace? Ok, we done that. Then we hit SOMETHING witch
isn't a constant, not namespace. Ups, what error should we give? Undefined
constant or missing namespace? Well, as i think of this - only good solution
is Fatal error, but then any forgottent to be set constant will result in
fatal error. To me that is good - I woun't forget to define any constants!
But as I predict - most will shout that it's too harsh, and they will be
right at some point (I myself started with a Pascal, so to me an undefined
variable === compile error (Fatal error in PHP terms), so it's natural to me
to have a Fatal at this point).
So -1 on "."
So . is more suitable than ::, but also has it's problems - easier o
resolve, but problems.
In thouse threads people presented next options for namespace separators:
1). ".." as separator. Well, two symbols, has no side effects, but looks
quite strage: namespace A..B::staticMethod(). I don't think it's a good one,
so -1.
2). Someone proposed \ as separator. A\B::staticMethod() - Looks crazy,
isn't it? And we all know, that \ mostly has special meaning in programming
languages as escape character. -1.
3). "#" & Co. A#B::staticMethod() - no side effects, bot looks dirty. -1
from me.
4). ::: or ::::. If ::: makes sence, than that man, who proposed :::: should
be joking. ::: - no side effects, just little more to type. A candidate.
Neither -1, nor +1.
So as prevoius speaker suggested, and I personaly got to conclusion in other
thread that ":" is ideal. Short, isn't taken.
<?php
D:F:G:B:H use A;
A:B::staticMethod();
A:B->test();
:phpversion();
?>
Looks great, clearly seen and distinguished from :: .
So maybe it is time to stop arguing and maybe use :? Because it finaly comes
out as good choise in many threads.
Please, think about us - developers! We don't want complicated resoution
rules. We don't want half functional namespaces with only classes or without
constants, ect. And : is something is natural, because we allready have ::
separator for static methods. Easy to understand, handy to use, everybody is
happy. Don't you want that?
+1 for : from me.
P.S. There always will be people, who will be against any suggestions.
Because that's phycology. They wana be in center of the attension. Just make
a vote thread about : and I think you will get a YES for that.
