namespaces and alpha3 View as Markdown

On Fri, Oct 10, 2008 at 5:56 PM, Geoffrey Sneddon <foolistbar@googlemail.com

wrote:

1. rip them out

I'm +1 on this. We simply don't have consensus, and I don't see anyway we
can have consensus by the time 5.3 has to be frozen. Once namespaces are in,
we're gonna have to stick with whatever we choose, unless we totally break
BC.

--
Geoffrey Sneddon
http://gsnedders.com/

I'd agree with this, leave something with such a big impact to version 6. At
least it gives time to get it right.

On Friday 10 October 2008 19:02:25 Stanislav Malyshev wrote:

Hi!

3. Stas proposal

I have two proposals, actually.

[snip]

2. Leave functions/constants as they are now, and add the following syntax:
   Class::Name->method()
   for calling static methods (and referring to class constants), so that
   there would be a way to disambiguate calls in (rare, IMHO) situations
   where ambiguity may arise.

This certainly seems like the best proposal.

Regards,
Stefan

Stanislav Malyshev wrote:

2. Leave functions/constants as they are now, and add the following syntax:
   Class::Name->method()
   for calling static methods (and referring to class constants), so that
   there would be a way to disambiguate calls in (rare, IMHO) situations
   where ambiguity may arise.

I would be glad with this one.

Thanks. Dmitry.

It should be noted that this proposal builds on Stas previous proposal
after Zendcon

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.

The original 3rd point from the proposal now has the following two
optional solutions (the first one being the originally proposed
approach):

I have two proposals, actually.

1. Leave functions (and constant) alone, i.e. namespace would ignore
   that.
   1.1 Option: if you define function inside namespace, compiler could
   give an error (I don't like this option, but I mention it for the
   sake of completeness).

I am -1 on this one.

2. Leave functions/constants as they are now, and add the following
   syntax:
   Class::Name->method()
   for calling static methods (and referring to class constants), so
   that there would be a way to disambiguate calls in (rare, IMHO)
   situations where ambiguity may arise.

I am +0.5(*) on this one. I dont like the fact that this means that
code needs to be migrated before being unambiguous, so I preferred the
idea of having a different separator between namespaces and its
members, but this way there is at least a solution available.

(*) There is a condition under which I would be +1 for the syntax. If
in PHP6 we can make the old syntax (A::foo() and A::FOO) raise an
E_STRICT (I dont think we ever want to remove it, so E_DEPRECATED
would not be the right choice), when its being used to reference class
members instead of namespace elements. If I understand the namespace
resolution rules properly, we check namespaces first before checking
for a class with the same name. So with the E_STRICT in place,
developers could protect themselves perfectly from accidental
ambiguities (if they were to ever introduce a namespace with the same
name as a class with a constant or static method that is referenced
using the double colon) and effectively migrate to the new syntax
(which I think is nicer anyways, than the original syntax).

Barring any new major findings I ask everybody to cast their vote by
Thursday evening PST. Since Dmitry was not happy with his proposal we
are left with:

1. Rip them out
2. Keep as is
3. Stas proposal with functions/constants ignored
4. Stas proposal with "->" optionally allowed to resolve ambiguities

If we have a decision by Thursday evening we could hopefully do an
alpha3 by Thursday the following week, although I would want any
namespace to be documented before (or closely around) the release of
alpha3. Stas said that he would be willing to update the README in a
timely manner after finishing a patch, in case we go for 3) or 4). I
hope we can also find the time to transfer any changes to docbook
quickly after this.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

Derick Rethans wrote:

At this point I guess we have the choice between:

1. rip them out
2. status quo
3. Stas proposal
4. Dmitrys proposal

Again I hope that Stas/Dmitry will give us an insight about their proposals,
though Stas proposal might or might not see any changes.

Stas wrote up an RFC about the two proposals:
http://wiki.php.net/rfc/namespaceref

Now I finally figured out what the two things are without having to real
a gazillion pointless posts it makes it easier to formulate my point of
view.

From my own point of view - which may well be flawed - I AM still seeing
'namespace' as a stepping stone to better code, but in order to achieve that
I am thinking that legacy sections get wrapped in a namespace while other
sections are developed. To that end, wrapping legacy functions and constant
does seem essential SHORT TERM, so not having them would seem to me to make
take-up of the concept hamstrung?

Am I being totally out of line with that idea? Is there a way to achieve the
same result with the current offering?

--
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

However, a third one might be to use a syntax separator that we've
not seen at all yet (I'd say ':::').

FWIW, this is my +0.5 (with +1 being dropping). I'm absolutely against
reusing a selector for this.

--
Geoffrey Sneddon
<http://gsnedders.com/

Am 15.10.2008 um 09:04 schrieb Derick Rethans:

As we're getting really close to 5.3, I would suggest to remove
namespaces from this release as we're simply not done with even
agreeing
on how things should work. PHP 5.3 has many other cool things, and
leaving namespaces for PHP 6 means we're actually introducing
functionality there as well (for the folks that don't care about
Unicode). We've done with namespaces for a loooong time, and they've
never really been required. Many people won't be able to use it any
way as they have to support older PHP versions in their code base as
well. PHP 6 is a much more natural switch for something like this.
If we absolutely have to have namespaces, then we should go with
the
"Namespaces without functions/constants" proposal, with some tweaks.
However, I still think it's not ready enough to put even that into
5.3.

My thoughts exactly. I realize it's a bold move, but it's a much
better alternative than the fuzz about an implementation that doesn't
work, or is incomplete, or needs to be broken in the future to add new
stuff.

• David

Hi!

It seems that we're not quite 100% how we want to do things. Reading the
"Namespaces with functions/constants" part of Stas' RFC makes me
cringe... just changing the behavior of -> and :: to just make things
work is a cludge, and a bad one at that. The other part, "Namespaces

I think that's actually what we should have done from the start. All OO
languages but C++ have same operator for both static and dynamic OO
access, and C++ is not exactly clarity example anyway. But we have the
baggage of being used to C++ way, so...

However, while reading code it makes it absolutely clear whether you're
using an internal class or not.

it is always absolutely clear - if you didn't say :: you are not.

As we're getting really close to 5.3, I would suggest to remove
namespaces from this release as we're simply not done with even agreeing
on how things should work. PHP 5.3 has many other cool things, and

You realize this means PHP will never have namespaces, right?

Unicode). We've done with namespaces for a loooong time, and they've
never really been required. Many people won't be able to use it any

For you, maybe, but for other people out there they are.

If we absolutely have to have namespaces, then we should go with the
"Namespaces without functions/constants" proposal, with some tweaks.

Which tweaks?

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

Lester Caine wrote:

What would be the advantage of wrapping legacy functions in a
namespace over wrapping them into a class as static functions?

THAT is probably why I am asking the question? And may well be key
to my understanding why converting non OO code into OO code in PHP
is so problematic. When I was coding in CC++ more heavily libraries
did not need to be objects and the 'namespace' just wrapped the
code OR the code was built as an object. That is what I understand
by a namespace, so perhaps I do not understand why leaving out
functions and constants is acceptable :(

I don't think there's any difference between moving non OO functions
to a class and making the static and moving those to a namespace (in
a suggested syntax it would be: Bar:::foo() for a namespace and
Bar::foo() already for a class). Even more, I think there are
advantages for moving a legacy app to a class because it allows you
to make your global variables (like things in legacy apps) class
members. Of course that's only an advantage if you agree that
globals are evil...

So my conclusion would be that leaving out functions and constants
is acceptable because there's no advantage of having those in a
namespace. Classes already provide everything you would possibly
want from namespaces for functions and constants.

well you cannot split a class definition across several files. so if
you move your functions to a class, you need to move them all to a
single file.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org