I thought that : was rejected because of the terniary operator? I'm not
going to search now for the discussion but for sure there were serious
objections against : , otherwise it would be natural to use it. How you
propose to handle the ambiguities like:
<?
print name1:name2?name3:name4:name5:name6;
/*
could mean:
$something?(namespace:namespace:constant) : (constant);
$something?(namespace:constant) : (namespace:constant);
and so on...
*/
?>
Parenthesis are a solution, but I have no knoledge of the internal parsing
hence I dont know is it possible.
AFAIK the actual problem with the current implementation with :: is that is
ambigous like:
<?
name1::name2();
/*
which could mean:
class::staticcall();
namespace::function();
and so on..
*/
?>
My proposal is (if possible/reasonable/performance wise of course) to have a
fatal error thrown when during the parse time the engine discovers
duplicates like the one described above. What is the point to name in the
same way a class and a static method and a namespace and a function in the
same way? In my (very humble) opinion this is the best solution, because we
keep the :: operator that we are familiar with, the ambiguity is resolved
(just not allowing it) and (I guess) the php 5.3 will not be delayed much.
Is there any other logical problem with the namespaces besides this
ambiguity? Have I missed something else?
In fact I'm using a lot the namespaces in their current implementation and
I'm very happy with it. I Never had problems with the ambiguity, because I
never even needed to use duplicated names for the different objects
(classes, constants, static methods, functions).
Vesselin Kenashkov
On Mon, Sep 29, 2008 at 7:05 PM, Arvids Godjuks <[EMAIL PROTECTED]>wrote:
> 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.
>
