namespace issues View as Markdown

Stanislav Malyshev schreef:

Hi!

On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:

1. Allow braces for namespaces. So, the syntax for namespaces will be:
   a) namespace foo;
   should be first (non-comment) statement in the file, namespace extends
   to the end of the file or next namespace declaration.
   b) namespace foo {}
   can appear anywhere on the top scope (can not be nested).
   Mixing both syntaxes in one file is not possible. The semantics of both
   syntaxes will be identical.

super. mixing of syntax is a parse error, right?
fancy taking a sportsmans bet as to which will be used more in the wild?
my 'money' is on syntax B. ;-)

2. Simplify resolution order for classes in the namespace: unqualified
   names are resolved this way:
   a) check "use" list if the name was defined at "use", follow that
   resolution
   b) if not, the name resolves to namespace::name
   Consequence of this will be that for using internal class inside
   namespace one would need to refer to it either as ::Foo or do use ::Foo
   prior to its usage.

again super ... by the sounds of it (I have a sneaking suspicion that
some edge-case resolution pains may still crop up but that's what edge-case are
all about ... if you could spot them all they'd call you <DEITY> :-))

3. Functions will not be allowed inside namespaces. We arrived to
   conclusion that they are much more trouble than they're worth, and
   summarily we would be better off without them. Most of the functionality
   could be easily achieved using static class methods, and the rest may be
   emulated with variable function names, etc.

given that the general distaste for Greg 'namespace member' proposal this
seems like the only other suitable option to resolve current ambiguity issues.

using abstract classes to 'namespace' functions has been a quite wide spread
practice for a while now anyway. it is likely that function() proponents will
balk at the idea of not being able to namespace them but that's less painful
to explain than having to deal with the current situation, imho.

which leaves the question of namespaced constants ... they suffer the same
problems as functions and can also be achieved via classes, I request that
you therefore remove them as well as functions.

rgds,
Jochem

PS - pity Greg's patch was so disliked, I rather liked it myself and would
have allowed constants and functions inside namespaces ... guess that's life :-)

Comments?

On Monday 22 September 2008 2:45:51 pm Stanislav Malyshev wrote:

Hi!

On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:

1. Allow braces for namespaces. So, the syntax for namespaces will be:
   a) namespace foo;
   should be first (non-comment) statement in the file, namespace extends
   to the end of the file or next namespace declaration.
   b) namespace foo {}
   can appear anywhere on the top scope (can not be nested).
   Mixing both syntaxes in one file is not possible. The semantics of both
   syntaxes will be identical.

To clarify, with syntax B you can do multiple namespaces in one file? I have
no objection then.

2. Simplify resolution order for classes in the namespace: unqualified
   names are resolved this way:
   a) check "use" list if the name was defined at "use", follow that
   resolution b) if not, the name resolves to namespace::name
   Consequence of this will be that for using internal class inside
   namespace one would need to refer to it either as ::Foo or do use ::Foo
   prior to its usage.

I am OK with this.

3. Functions will not be allowed inside namespaces. We arrived to
   conclusion that they are much more trouble than they're worth, and
   summarily we would be better off without them. Most of the functionality
   could be easily achieved using static class methods, and the rest may be
   emulated with variable function names, etc.

Comments?

"Most of the functionality could be easily achieved using static class
methods".

As someone who uses both functions and classes with equal comfort, I have to
say "GAH, NO NO NO!" to that statement. Classes as pseudo-namespaces are
fundamentally wrong. Conceptually they're entirely different things. I have
to shut people down every time they try to suggest that in Drupal.

It's not just a conceptual issue, either. For a very practical example,
consider that a namespaces can be split across any number of files. A class
must be all in one file. That means if you want to group functions together,
they MUST all be in one single monolithic file. That makes them, sorry,
useless for anything even remotely interesting.

No, namespaces for functions can most certainly not be emulated with either
variable functions or static methods. Dropping namespace support for
functions makes namespaces mostly useless for anyone who is not 100% OOP.
There's no reason to make functions second-class citizens (no pun intended).

--
Larry Garfield
larry@garfieldtech.com

Stanislav Malyshev wrote:

Hi!

On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:
.....

3. Functions will not be allowed inside namespaces. We arrived to
   conclusion that they are much more trouble than they're worth, and
   summarily we would be better off without them. Most of the functionality
   could be easily achieved using static class methods, and the rest may be
   emulated with variable function names, etc.

Comments?
IF Functions can not be wrapped in a namespace then what IS the object of
namespace?
I understood that namespace was to be a wrapper so that things with the same
internal name could be isolated? If one of the main elements of a library
can't then be included in the library namespace is there ANY point in adding
namespaces at all?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

Stanislav Malyshev wrote:

Hi!

On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:

1. Allow braces for namespaces. So, the syntax for namespaces will be:
   a) namespace foo;
   should be first (non-comment) statement in the file, namespace extends
   to the end of the file or next namespace declaration.
   b) namespace foo {}
   can appear anywhere on the top scope (can not be nested).
   Mixing both syntaxes in one file is not possible. The semantics of both
   syntaxes will be identical.

2. Simplify resolution order for classes in the namespace: unqualified
   names are resolved this way:
   a) check "use" list if the name was defined at "use", follow that
   resolution
   b) if not, the name resolves to namespace::name
   Consequence of this will be that for using internal class inside
   namespace one would need to refer to it either as ::Foo or do use ::Foo
   prior to its usage.

3. Functions will not be allowed inside namespaces. We arrived to
   conclusion that they are much more trouble than they're worth, and
   summarily we would be better off without them. Most of the functionality
   could be easily achieved using static class methods, and the rest may be
   emulated with variable function names, etc.

Comments?

Great, lets castrate the language to make it consistent. :(

1. I am fine with (1), except for unspecified scope of "use" statement
   inside namespace with bracket. I assume it should affect only current
   declaration and not the following namespace declarations (even with the
   same name).

2. This is acceptable only if we accept (3) otherwise we will need to
   write ::strlen() and so on.

3. In case we remove functions we also need to remove constants as they
   have exactly the same ambiguity problems. It's unclear for me what the
   following code will define after all (global function or just emit a
   parse error?)

<?php
namespace foo {
function bar() {
}
}
?>

Thanks. Dmitry.

On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk
about what we'd like to do with namespaces, and we arrived at the
following conclusions, which we propose to implement in 5.3:

1. Allow braces for namespaces.

2. Simplify resolution order for classes in the namespace: unqualified
   names are resolved this way:
   a) check "use" list if the name was defined at "use", follow that
   resolution
   b) if not, the name resolves to namespace::name

3. Functions will not be allowed inside namespaces.

Comments?

+1

regards,
Derick

--
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

Hi Stas,

Am Montag, den 22.09.2008, 12:45 -0700 schrieb Stanislav Malyshev:
[...]

On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:

Thanks for the effort.

1. Allow braces for namespaces. So, the syntax for namespaces will be:
   a) namespace foo;
   should be first (non-comment) statement in the file, namespace extends
   to the end of the file or next namespace declaration.
   b) namespace foo {}
   can appear anywhere on the top scope (can not be nested).
   Mixing both syntaxes in one file is not possible. The semantics of both
   syntaxes will be identical.

2. Simplify resolution order for classes in the namespace: unqualified
   names are resolved this way:
   a) check "use" list if the name was defined at "use", follow that resolution
   b) if not, the name resolves to namespace::name
   Consequence of this will be that for using internal class inside
   namespace one would need to refer to it either as ::Foo or do use ::Foo
   prior to its usage.

3. Functions will not be allowed inside namespaces. We arrived to
   conclusion that they are much more trouble than they're worth, and
   summarily we would be better off without them. Most of the functionality
   could be easily achieved using static class methods, and the rest may be
   emulated with variable function names, etc.

+1

cu, Lars

Jabber: lars@strojny.net
Weblog: http://usrportage.de

Hi.

For what it's worth, my point of view:

Stanislav Malyshev wrote:

1. Allow braces for namespaces. So, the syntax for namespaces will be:
   a) namespace foo;
   should be first (non-comment) statement in the file, namespace extends
   to the end of the file or next namespace declaration.
   b) namespace foo {}
   can appear anywhere on the top scope (can not be nested).

Full support for the braces, but please donot* allow both ways. Why?
Perl's "more than one way to do it"? If there's one way, it's clear what
to use. I see absolutely no point in this. Really. Please don't.

2. Simplify resolution order for classes in the namespace: unqualified
   names are resolved this way:
   a) check "use" list if the name was defined at "use", follow that
   resolution
   b) if not, the name resolves to namespace::name
   Consequence of this will be that for using internal class inside
   namespace one would need to refer to it either as ::Foo or do use ::Foo
   prior to its usage.

Fine with me. I'd use ::Foo for internal classes anyway to avoid speed
and ambiguity issues.

3. Functions will not be allowed inside namespaces. We arrived to
   conclusion that they are much more trouble than they're worth, and
   summarily we would be better off without them. Most of the functionality
   could be easily achieved using static class methods, and the rest may be
   emulated with variable function names, etc.

We roll everything in classes anyway, so fine with me.

Regards,
Karsten

Sounds fantastic to me.
Not a fan of the {} namespaces but each to their own.

Hi!

On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:

1. Allow braces for namespaces. So, the syntax for namespaces will be:
   a) namespace foo;
   should be first (non-comment) statement in the file, namespace extends to
   the end of the file or next namespace declaration.
   b) namespace foo {}
   can appear anywhere on the top scope (can not be nested).
   Mixing both syntaxes in one file is not possible. The semantics of both
   syntaxes will be identical.

2. Simplify resolution order for classes in the namespace: unqualified names
   are resolved this way:
   a) check "use" list if the name was defined at "use", follow that resolution
   b) if not, the name resolves to namespace::name
   Consequence of this will be that for using internal class inside namespace
   one would need to refer to it either as ::Foo or do use ::Foo prior to its
   usage.

3. Functions will not be allowed inside namespaces. We arrived to conclusion
   that they are much more trouble than they're worth, and summarily we would
   be better off without them. Most of the functionality could be easily
   achieved using static class methods, and the rest may be emulated with
   variable function names, etc.

Comments?

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

Am 22.09.2008 um 21:45 schrieb Stanislav Malyshev:

On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk
about what we'd like to do with namespaces, and we arrived at the
following conclusions, which we propose to implement in 5.3:

1. Allow braces for namespaces. So, the syntax for namespaces will be:

2. Simplify resolution order for classes in the namespace:
   unqualified names are resolved this way:

3. Functions will not be allowed inside namespaces.

Comments?

+1

• David

Hi,

1. and 2. are great. I'm happy to see this done.

But for 3. I think that's throwing the baby with the bathwater.

Since now global classes inside namespaces will need the "use ::Foo;" or
"::Foo...", I hope you can give a fresh look at my original idea that both
functions and classes require the "use ::foo" or "::foo()" when in a
namespace, and leave namespaced functions in.

Regards,
Stan Vassilev

Stanislav Malyshev wrote:

Hi!

On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:

1. Allow braces for namespaces. So, the syntax for namespaces will be:
   a) namespace foo;
   should be first (non-comment) statement in the file, namespace extends
   to the end of the file or next namespace declaration.
   b) namespace foo {}
   can appear anywhere on the top scope (can not be nested).
   Mixing both syntaxes in one file is not possible. The semantics of both
   syntaxes will be identical.

2. Simplify resolution order for classes in the namespace: unqualified
   names are resolved this way:
   a) check "use" list if the name was defined at "use", follow that
   resolution
   b) if not, the name resolves to namespace::name
   Consequence of this will be that for using internal class inside
   namespace one would need to refer to it either as ::Foo or do use ::Foo
   prior to its usage.

3. Functions will not be allowed inside namespaces. We arrived to
   conclusion that they are much more trouble than they're worth, and
   summarily we would be better off without them. Most of the functionality
   could be easily achieved using static class methods, and the rest may be
   emulated with variable function names, etc.

I'm happy with

#1 although I prefer 1 syntax to rule them all, I can live with this
#2
#3 if it also includes removing namespace constants

For future post-5.3, functions could be added back in. The ambiguity
issue could easily be fixed by having a different scoping resolution
operator for namespaced classes vs. namespaced functions/consts. For
instance:

<?php
blah::thing::mymethod(); // namespaced class blah::thing, method call to
mymethod
echo blah::thing::constant; // namespaced class blah::thing, class
constant constant
blah::thing:>func(); // namespaced function blah::thing:>func
echo blah::thing:>constant; // namespaced constant blah::thing:>constant
blah::thing:>$var = 1; // namespaced variable blah::thing:>$var (pure
fantasy, but illustrates the point)
blah::thing::$var = 1; // namespaced class blah::thing, class variable $var
?>

Before anyone gets all hyper, my point is not to introduce :>, but to
explain that it is in fact technically feasible to extend the definition
of namespaces later to add support for non-class elements and it would
work just fine.

It is, however, not going to be possible to do this post-5.3 without the
change above.

Note that we have a different operator for dereferencing static class
members (::) versus object members (->) for the reason that the thing
being dereferenced is different. Namespaces are in fact different from
classes, so the problem with the current implementation is that the same
operator (::) used for both means we cannot allow any ambiguity between
namespace contents and class contents.

As long as classes cannot contain other classes:

<?php
class one {
class dearGodNO {}
}
?>

then :: can be used for both namespace operator and static class
operator if functions/constants are removed from namespaces.

Greg

2008/9/22 Stanislav Malyshev stas@zend.com

Hi!

3. Functions will not be allowed inside namespaces. We arrived to
   conclusion that they are much more trouble than they're worth, and summarily
   we would be better off without them. Most of the functionality could be
   easily achieved using static class methods, and the rest may be emulated
   with variable function names, etc.

Comments?

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

--

That means, that if I have a tiny, 70-100 line script and I use a package in
a namespace with some global functionality - it should be 100% OOP? Sorry,
but that's OOP for the sake of OOP. It's like writing "Hello world!" using
patterns (here is an example:
http://www.phppatterns.com/docs/design/hello_world_in_patterns)

-1 on this.

Hi,

1. Allow braces for namespaces. So, the syntax for namespaces will be:
   a) namespace foo;
   should be first (non-comment) statement in the file, namespace extends
   to the end of the file or next namespace declaration.
   b) namespace foo {}
   can appear anywhere on the top scope (can not be nested).
   Mixing both syntaxes in one file is not possible. The semantics of both
   syntaxes will be identical.

I'm fine with that, personally I'd like having only the {}-Syntax but as
many people want both, well, ...
For future times (6.0) we might think about adding nesting support - if
we get it working good with the engine, but no show-stopper, we're
"delayed" enough...

2. Simplify resolution order for classes in the namespace: unqualified
   names are resolved this way:
   a) check "use" list if the name was defined at "use", follow that resolution
   b) if not, the name resolves to namespace::name
   Consequence of this will be that for using internal class inside
   namespace one would need to refer to it either as ::Foo or do use ::Foo
   prior to its usage.

That will hurt a bit when working with DOM for example, but still +1.

3. Functions will not be allowed inside namespaces. We arrived to
   conclusion that they are much more trouble than they're worth, and
   summarily we would be better off without them. Most of the functionality
   could be easily achieved using static class methods, and the rest may be
   emulated with variable function names, etc.

That's fine, I'm not sure about constants, neither one way nor the
other, but in general I see some support for dropping them.

johannes

I'm -1 for "removing constants and functions from the namespaces". As I
wrote already in another thread, is it possible to have a fatal error thrown
when the engine detects an ambiguity situation? Are there any logical (i
mean from OOP point of view) or internals (performance and so on) problems
with this solution? In my opinion is better than dropping funcs & consts.

Vesselin Kenashkov

Hi!

On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:

1. Allow braces for namespaces. So, the syntax for namespaces will be:
   a) namespace foo;
   should be first (non-comment) statement in the file, namespace extends to
   the end of the file or next namespace declaration.
   b) namespace foo {}
   can appear anywhere on the top scope (can not be nested).
   Mixing both syntaxes in one file is not possible. The semantics of both
   syntaxes will be identical.

2. Simplify resolution order for classes in the namespace: unqualified
   names are resolved this way:
   a) check "use" list if the name was defined at "use", follow that
   resolution
   b) if not, the name resolves to namespace::name
   Consequence of this will be that for using internal class inside namespace
   one would need to refer to it either as ::Foo or do use ::Foo prior to its
   usage.

3. Functions will not be allowed inside namespaces. We arrived to
   conclusion that they are much more trouble than they're worth, and summarily
   we would be better off without them. Most of the functionality could be
   easily achieved using static class methods, and the rest may be emulated
   with variable function names, etc.

Comments?

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

Stanislav Malyshev wrote:

Hi!

On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:

1. Allow braces for namespaces. So, the syntax for namespaces will be:
   a) namespace foo;
   should be first (non-comment) statement in the file, namespace extends
   to the end of the file or next namespace declaration.
   b) namespace foo {}
   can appear anywhere on the top scope (can not be nested).
   Mixing both syntaxes in one file is not possible. The semantics of both
   syntaxes will be identical.

2. Simplify resolution order for classes in the namespace: unqualified
   names are resolved this way:
   a) check "use" list if the name was defined at "use", follow that
   resolution
   b) if not, the name resolves to namespace::name
   Consequence of this will be that for using internal class inside
   namespace one would need to refer to it either as ::Foo or do use ::Foo
   prior to its usage.

3. Functions will not be allowed inside namespaces. We arrived to
   conclusion that they are much more trouble than they're worth, and
   summarily we would be better off without them. Most of the functionality
   could be easily achieved using static class methods, and the rest may be
   emulated with variable function names, etc.

Comments?

Figuring that you arrived at the same conclusion nearly three years ago
regarding my namespace patch, and I also agreed that only classes should
be allowed inside namespaces
(http://marc.info/?l=php-internals&m=113320797607651&w=2), I am +1 for
this proposal.

--

Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)