Everything

php

Home » Project » Newsgroups » php.internals » Namespaces bug »

Namespaces bug

php.internals

Andrei Zmievski

23 years ago

namespace A {
namespace B{
class C {
function D() { print "asdf\n"; }
}
}

}

B::C::D();

Apparently, the parser allows nesting namespaces, but they are all
registered as global ones. Should be fixed, I think.

-Andrei                                       http://www.gravitonic.com/

Windows 2000 is certified not to crash more than
once a day, so what is the bootup time, 24 hours?
-- Sam Liddicott

Stanislav Malyshev

23 years ago

Noting to fix. This is by design.

AZ>> namespace A {
AZ>>     namespace B{
AZ>>         class C {
AZ>>             function D() { print "asdf\n"; }
AZ>>         }
AZ>>     }
AZ>>
AZ>> }
AZ>>
AZ>> B::C::D();
AZ>>
AZ>> Apparently, the parser allows nesting namespaces, but they are all
AZ>> registered as global ones. Should be fixed, I think.
AZ>>
AZ>> -Andrei                                       http://www.gravitonic.com/
AZ>>
AZ>> Windows 2000 is certified not to crash more than
AZ>> once a day, so what is the bootup time, 24 hours?
AZ>> -- Sam Liddicott
AZ>>
AZ>>

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.109

Andrei Zmievski

23 years ago

Care to explain a little more? I think allowing this syntax is very
confusing for the user.

I can see the point of this:

namespace A {
class B {
...
}
}

...

namespace A {
class C {
...
}
}

But not in the example below. People would basically expect to have
nested namespaces, which we don't have, so why lead them on?

On Wed, 26 Mar 2003, Stanislav Malyshev wrote:

> Noting to fix. This is by design.
>
> AZ>> namespace A {
> AZ>>     namespace B{
> AZ>>         class C {
> AZ>>             function D() { print "asdf\n"; }
> AZ>>         }
> AZ>>     }
> AZ>>
> AZ>> }
> AZ>>
> AZ>> B::C::D();
> AZ>>
> AZ>> Apparently, the parser allows nesting namespaces, but they are all
> AZ>> registered as global ones. Should be fixed, I think.

-Andrei                                       http://www.gravitonic.com/
* The great thing about standards is that there are so many to choose from. *

Rasmus Lerdorf

23 years ago

Couldn't you make the same argument for:

function A() {
function B() {
}
}

This has worked for years and both A() and B() become global functions.

-Rasmus

On Wed, 26 Mar 2003, Andrei Zmievski wrote:

Andrei Zmievski

23 years ago

On Wed, 26 Mar 2003, Rasmus Lerdorf wrote:

> Couldn't you make the same argument for:
>
>   function A() {
>     function B() {
>     }
>   }
>
> This has worked for years and both A() and B() become global functions.

Yes, but that's a remnant of the old syntax. We shouldn't introduce new
cruft if we don't have to.

-Andrei                                       http://www.gravitonic.com/

"The secret of flying is to throw yourself
at the ground, and miss." -- Douglas Adams

Shane Caraveo

23 years ago

Rasmus Lerdorf wrote:

> Couldn't you make the same argument for:
>
>   function A() {
>     function B() {
>     }
>   }

I would :)

The syntax is meaningless and confusing if the program does not operate
the way it is written.  By all sensible considerations, B should be
local to A.  Since it is not, the syntax should cause a parser error,
and the same with namespaces.  And then what happens with that stuff
when, at some point in the future, proper scoping is implemented?

Shane

Andrei Zmievski

23 years ago

On Wed, 26 Mar 2003, Shane Caraveo wrote:

> The syntax is meaningless and confusing if the program does not operate
> the way it is written.  By all sensible considerations, B should be
> local to A.  Since it is not, the syntax should cause a parser error,
> and the same with namespaces.  And then what happens with that stuff
> when, at some point in the future, proper scoping is implemented?

Precisely.

-Andrei                                       http://www.gravitonic.com/
* Quantum Mechanics: The Dreams of Which Stuff is Made. *

Sascha Schumann

23 years ago

> The syntax is meaningless and confusing if the program does not operate
> the way it is written.  By all sensible considerations, B should be
> local to A.  Since it is not, the syntax should cause a parser error,
> and the same with namespaces.  And then what happens with that stuff
> when, at some point in the future, proper scoping is implemented?

Fully agreed.

- Sascha

Derick Rethans

23 years ago

On Wed, 26 Mar 2003, Sascha Schumann wrote:

> > The syntax is meaningless and confusing if the program does not operate
> > the way it is written.  By all sensible considerations, B should be
> > local to A.  Since it is not, the syntax should cause a parser error,
> > and the same with namespaces.  And then what happens with that stuff
> > when, at some point in the future, proper scoping is implemented?
>
>     Fully agreed.

Same here.

Derick

--
"my other box is your windows PC"
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals       http://php-mag.net/
-------------------------------------------------------------------------

Rasmus Lerdorf

23 years ago

On Wed, 26 Mar 2003, Shane Caraveo wrote:

> Rasmus Lerdorf wrote:
> > Couldn't you make the same argument for:
> >
> >   function A() {
> >     function B() {
> >     }
> >   }
>
> I would :)
>
> The syntax is meaningless and confusing if the program does not operate
> the way it is written.  By all sensible considerations, B should be
> local to A.  Since it is not, the syntax should cause a parser error,
> and the same with namespaces.  And then what happens with that stuff
> when, at some point in the future, proper scoping is implemented?

I'm not arguing that it is correct, I am simply saying that it is exactly
the same issue and it doesn't make a whole lot of sense to me to disallow
it for namespaces, but allow it for functions.

-Rasmus

George Schlossnagle

23 years ago

On Wednesday, March 26, 2003, at 02:36  PM, Rasmus Lerdorf wrote:

> On Wed, 26 Mar 2003, Shane Caraveo wrote:
>
>> Rasmus Lerdorf wrote:
>>> Couldn't you make the same argument for:
>>>
>>>   function A() {
>>>     function B() {
>>>     }
>>>   }
>>
>> I would :)
>>
>> The syntax is meaningless and confusing if the program does not
>> operate
>> the way it is written.  By all sensible considerations, B should be
>> local to A.  Since it is not, the syntax should cause a parser error,
>> and the same with namespaces.  And then what happens with that stuff
>> when, at some point in the future, proper scoping is implemented?
>
> I'm not arguing that it is correct, I am simply saying that it is
> exactly
> the same issue and it doesn't make a whole lot of sense to me to
> disallow
> it for namespaces, but allow it for functions.

I think that the argument is that it would be best to disallow it both
places, but doing so would break bc for functions.  Two wrongs don't
make a right, though.  Just because there have been confusing syntax
choices in the past doesn't mean they should be propagated into the
future.

Stanislav Malyshev

23 years ago

>> > local to A.  Since it is not, the syntax should cause a parser error,
>> > and the same with namespaces.  And then what happens with that stuff
>> > when, at some point in the future, proper scoping is implemented?

Well, I don't know for the future and stuff. I talked with Andi and he
agrees with you (i.e., he doesn't see a use in nested namespaces) so I
would probably un-nest them.

Also, I think that include() (and its brothers) should be not part of the
namespace even if called from the namespace code (just like include from
class function is not in the class).

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.109

Andrei Zmievski

23 years ago

On Wed, 26 Mar 2003, Stanislav Malyshev wrote:

> Well, I don't know for the future and stuff. I talked with Andi and he
> agrees with you (i.e., he doesn't see a use in nested namespaces) so I
> would probably un-nest them.
>
> Also, I think that include() (and its brothers) should be not part of the
> namespace even if called from the namespace code (just like include from
> class function is not in the class).

Can you ask Andi about the doc comment patch I sent him while you're at
it? If he or Zeev don't have time, maybe you can take a look?

-Andrei                                       http://www.gravitonic.com/
* Programming is an art form that fights back. *

Shane Caraveo

23 years ago

Rasmus Lerdorf wrote:

> On Wed, 26 Mar 2003, Shane Caraveo wrote:
>
>
>>Rasmus Lerdorf wrote:
>>
>>>Couldn't you make the same argument for:
>>>
>>>  function A() {
>>>    function B() {
>>>    }
>>>  }
>>
>>I would :)
>>
>>The syntax is meaningless and confusing if the program does not operate
>>the way it is written.  By all sensible considerations, B should be
>>local to A.  Since it is not, the syntax should cause a parser error,
>>and the same with namespaces.  And then what happens with that stuff
>>when, at some point in the future, proper scoping is implemented?
>
>
> I'm not arguing that it is correct, I am simply saying that it is exactly
> the same issue and it doesn't make a whole lot of sense to me to disallow
> it for namespaces, but allow it for functions.
>

Didn't figure you were, I'm simply arguing that it shouldn't be allowed
for either.  It doesn't serve any usefull purpose and has negative
impact, and since this is a major version change, so we should feel free
to break a bit of BC in places like this.

Shane

George Schlossnagle

23 years ago

On Wednesday, March 26, 2003, at 02:46  PM, Shane Caraveo wrote:

> Didn't figure you were, I'm simply arguing that it shouldn't be
> allowed for either.  It doesn't serve any usefull purpose and has
> negative impact, and since this is a major version change, so we
> should feel free to break a bit of BC in places like this.

I think the breaking of include guards:

//a.php
if(A_PHP) {
return;
}
define('A_PHP',1);

function a() {}



// b.php
include "a.php";
include "a.php";


is a much bigger bc break (though not necessarily a bad one).

George

(Marcus Börger)

23 years ago

At 19:45 26.03.2003, Shane Caraveo wrote:

>Rasmus Lerdorf wrote:
>>Couldn't you make the same argument for:
>>   function A() {
>>     function B() {
>>     }
>>   }
>
>I would :)
>
>The syntax is meaningless and confusing if the program does not operate
>the way it is written.  By all sensible considerations, B should be local
>to A.  Since it is not, the syntax should cause a parser error, and the
>same with namespaces.  And then what happens with that stuff when, at some
>point in the future, proper scoping is implemented?

Lets disallow both nesting function and NOT WORKING nested namespaces (and
classes?) for PHP5.
We changed a lot and took care about BC issues even more but why not get
rid of these shit? AND
why introducing even more nonsense?

marcus

Andi Gutmans

23 years ago

At 08:43 PM 3/26/2003 +0100, Marcus Börger wrote:

>Lets disallow both nesting function and NOT WORKING nested namespaces (and
>classes?) for PHP5.
>We changed a lot and took care about BC issues even more but why not get
>rid of these shit? AND
>why introducing even more nonsense?

I definitely don't think we should break BC. I've always thought of having
some kind of E_PURIST methods which would give a warning for stuff we don't
consider nice or things which might be deprecated one time in the future.

Andi

(Marcus Börger)

23 years ago

At 21:22 26.03.2003, Andi Gutmans wrote:

>At 08:43 PM 3/26/2003 +0100, Marcus Börger wrote:
>
>>Lets disallow both nesting function and NOT WORKING nested namespaces
>>(and classes?) for PHP5.
>>We changed a lot and took care about BC issues even more but why not get
>>rid of these shit? AND
>>why introducing even more nonsense?
>
>
>I definitely don't think we should break BC. I've always thought of having
>some kind of E_PURIST methods which would give a warning for stuff we
>don't consider nice or things which might be deprecated one time in the future.

I once thought about W_HINT (like Delphi does) this would allow some more
things helpful during development.

marcus

George Schlossnagle

23 years ago

What is the value of that syntax?  That seems entirely confiusing to
me.  If

namespace A { namespace B {} }

doesn't create a nested namespace, what is the value of having it?

On Wednesday, March 26, 2003, at 01:10  PM, Stanislav Malyshev wrote:

Sterling Hughes

23 years ago

On Wed, 2003-03-26 at 13:18, George Schlossnagle wrote:

> What is the value of that syntax?  That seems entirely confiusing to
> me.  If
>
> namespace A { namespace B {} }
>

I believe the way it was designed was:

namespace A {
namespace A:B {
class C {
}
}
}

-Sterling

PS: Not 'for' or 'against,' I just remembered that as one of the
arguments.

> doesn't create a nested namespace, what is the value of having it?
>
> On Wednesday, March 26, 2003, at 01:10  PM, Stanislav Malyshev wrote:
>
> > Noting to fix. This is by design.
> >
> > AZ>> namespace A {
> > AZ>>     namespace B{
> > AZ>>         class C {
> > AZ>>             function D() { print "asdf\n"; }
> > AZ>>         }
> > AZ>>     }
> > AZ>>
> > AZ>> }
> > AZ>>
> > AZ>> B::C::D();
> > AZ>>
> > AZ>> Apparently, the parser allows nesting namespaces, but they are all
> > AZ>> registered as global ones. Should be fixed, I think.
> > AZ>>
> > AZ>> -Andrei
> > http://www.gravitonic.com/
> > AZ>>
> > AZ>> Windows 2000 is certified not to crash more than
> > AZ>> once a day, so what is the bootup time, 24 hours?
> > AZ>> -- Sam Liddicott
> > AZ>>
> > AZ>>
> >
> > --
> > Stanislav Malyshev, Zend Products Engineer
> > stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.109
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >

--
--
"That stuff's easy compared to installing horde :)"
- Alan Knowles, In response to my applause for creating a LALR
parser for PHP.

Stanislav Malyshev

23 years ago

SH>> I believe the way it was designed was:
SH>>
SH>> namespace A {
SH>>     namespace A:B {
SH>>        class C {
SH>>        }
SH>>     }
SH>> }

That's the same thing. As was noted repeatedly on the lists, ':' has no
semantic meaning, A and A:B are not related in any way.

One again:
Namespaces are not 'nested'. You can define namespace inside other
namespace, this does not make them related. There's no namespace nesting.
':' in namespace name does not mean anything.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.109

Derick Rethans

23 years ago

On Wed, 26 Mar 2003, Stanislav Malyshev wrote:

> SH>> I believe the way it was designed was:
> SH>>
> SH>> namespace A {
> SH>>     namespace A:B {
> SH>>        class C {
> SH>>        }
> SH>>     }
> SH>> }
>
> That's the same thing. As was noted repeatedly on the lists, ':' has no
> semantic meaning, A and A:B are not related in any way.
>
> One again:
> Namespaces are not 'nested'. You can define namespace inside other
> namespace, this does not make them related. There's no namespace nesting.
> ':' in namespace name does not mean anything.

But it *is* confusing (just as function() { function() {} }, but of
course we can not change that anymore). What is the reason of allowing
this 'nested' stuff?

Derick

--
"my other box is your windows PC"
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals       http://php-mag.net/
-------------------------------------------------------------------------

Stanislav Malyshev

23 years ago

DR>> But it *is* confusing (just as function() { function() {} }, but of
DR>> course we can not change that anymore). What is the reason of
DR>> allowing this 'nested' stuff?

Because someone asked for it. I don't see why it is so bad.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.109

Andrei Zmievski

23 years ago

On Wed, 26 Mar 2003, Stanislav Malyshev wrote:

> Because someone asked for it. I don't see why it is so bad.

Heh, I've asked for a lot of things that didn't make it into the engine.
:) The badness of it is the confusion it will cause.

-Andrei                                       http://www.gravitonic.com/
* "I'll need daily status reports on why you're so behind." -- Dilbert's boss *

Shane Caraveo

23 years ago

Stanislav Malyshev wrote:

> DR>> But it *is* confusing (just as function() { function() {} }, but of
> DR>> course we can not change that anymore). What is the reason of
> DR>> allowing this 'nested' stuff?
>
> Because someone asked for it. I don't see why it is so bad.
>

That's a bad reason for a bad feature.  Syntax should imply
functionality.  Give that code to someone who's never used/seen php
code, and it will imply something completely incorrect.  Stuff like this
degrades PHP's 'ease of use and learning'.

Shane

Sterling Hughes

23 years ago

On Wed, 2003-03-26 at 13:35, Stanislav Malyshev wrote:

> SH>> I believe the way it was designed was:
> SH>>
> SH>> namespace A {
> SH>>     namespace A:B {
> SH>>        class C {
> SH>>        }
> SH>>     }
> SH>> }
>
> That's the same thing. As was noted repeatedly on the lists, ':' has no
> semantic meaning, A and A:B are not related in any way.
>
> One again:
> Namespaces are not 'nested'. You can define namespace inside other
> namespace, this does not make them related. There's no namespace nesting.
> ':' in namespace name does not mean anything.

I know, its synactic sugar to give the illusion of nesting.  I was just
pointing out that I believe that is how it was meant to 'look.'

-Sterling

--
"I can't give you a brain, so I'll give you a diploma"
- The Great Oz, The Wizard of Oz