my last attempt at sanity with namespaces

17 years ago by Guilherme Blanco — view source — reply

unread

Hi,

I spent almost all day long reading your emails about ns
implementation (including one 100+ thread).

There are many useless discussions to be honest, some of them almost
going to personal side.
I think this should be a simple thread of voting, instead of start
another flame war here.

For those that are considering only karma people, I help Pierre with
windows website.

Here are my votes:

Namespace resolution issue:

explicit disambiguation with "use namespace blah::blah;" or "use
class blah::blah;"

__autoload calling order change:

I think a lot of people will have to adapt their implementation to
not through Exception if class is not found (You can check that many
tools do that).
This will end up with always falling into your "autoload call escape
fix" hint. So, I can live with it without troubles.

You have a big one thumb up from me!

Regards,

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

--

--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil

17 years ago by Kalle Sommer Nielsen — view source — reply

unread

Hi

Like Guilherme wrote, I've spend alot of my day reading the emails and
trying to understand the namespace issues and after reading your
proposal I understand the issues you're bringing up. So heres my
votes:

Conflict between namespaced functions and static class methods:
I don't think it makes much sense to be able to make a class inside a
namespace with the same name as another namespace, so my +1 here goes
to option #4 (disallow mixing namespaces and classes with the same
name).

Resolving access to internal classes:
I'm a +1 for changing the resolution order.

Cheers,
Kalle Sommer Nielsen

17 years ago by Nathan Rixham — view source — reply

unread

Kalle Sommer Nielsen wrote:

Hi

Like Guilherme wrote, I've spend alot of my day reading the emails and
trying to understand the namespace issues and after reading your
proposal I understand the issues you're bringing up. So heres my
votes:

Conflict between namespaced functions and static class methods:
I don't think it makes much sense to be able to make a class inside a
namespace with the same name as another namespace, so my +1 here goes
to option #4 (disallow mixing namespaces and classes with the same
name).

Resolving access to internal classes:
I'm a +1 for changing the resolution order.

Cheers,
Kalle Sommer Nielsen

out of the four options I'm:
+1 to (disallow mixing namespaces and classes with the same name)
+5 to changing the :: namespace operator personally I like period(.)

IMO
::: is visually and legibly dire

you can't namespace::class:::static_method() [or change the
class::static() operator at all] as that would mean every reference to a
static method in a class since eternity was using the wrong operator

"use namespace"/"use class" syntax seems to bloat but certainly isn't
disambiguous

or use something completely mad like uri scheme's for namespaces!
ns://one/step/two()
ns://one/step::two()
[the last comment should probably be disregarded]

17 years ago by konference@kukulich.net — view source — reply

unread

Hi,

I have no karma but I read almost all threads about namespaces and I
think I understand the issues.

Conflict between namespaced functions and static class methods:
I prefer #1 but #3 is also good.
Resolving access to internal classes:
+1 for the solution.

Please don't remove namespaces from 5.3. We are really waiting for them.

Regards

17 years ago by Elizabeth M Smith — view source — reply

unread

Greg Beaver wrote:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

Greg already knows how I feel - but for the rest of you

+1 for #1 or #3 (greg has a patch for 3) - either way works great for my
purposes

+1 and of course make the resolution as greg mentioned on the rfc in the
resolving access part (actually that was in stas's original original
post and I didn't realize we were still arguing over it ;)

Then I am ready to roll and will cease whining ;)

Thanks for your work Greg,

Elizabeth Smith

17 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

+1 and of course make the resolution as greg mentioned on the rfc in the
resolving access part (actually that was in stas's original original
post and I didn't realize we were still arguing over it ;)

NO, it wasn't in my proposal - my proposal was entirely different. My
proposal does not include autoload performance bomb.

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

17 years ago by Andrei Zmievski — view source — reply

unread

Thank you for the voice of sanity, Greg. I agree with your approach.

-Andrei

Greg Beaver wrote:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

17 years ago by Janusz Lewandowski — view source — reply

unread

Hi,

Conflict between namespaced functions and static class methods:
I think that #4 solution is the best one. If it will be accepted, it would be
possible to extend namespaces in PHP6. For example, it would be possible to
allow mixing namespaces and classes with same names, and disallow only mixing
namespaced functions / static class methods. PHP 5.3 is too nearly for such a
change, but in PHP6 you can make static class methods the same thing as
functions and namespaced functions, with one additional feature for them (and
maybe namespaced functions) - support for self::, static:: and parent::. This
way, it will be also possible to add support for having both dynamic method
and static method with the same name, but e.g. other parameters (like
String::substring($string, 4, 2) and $string->substring(4, 2)).

Resolving access to internal classes:
I like your solution, it's much better than current resolution rules.

Janusz Lewandowski

17 years ago by Steph Fox — view source — reply

unread

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

It sure would :)

"Conflict between namespaced functions and static class methods"

#3 is sheer brilliance IMHO. No BC issues for Karsten and friends, nice
clear warnings on conflict and an easy way to fix them (I saw the draft
patch), no performance hit any place that should matter, and above all -
nobody else even thought of approaching the problem from that end in all
this time, so kudos to you!
Since I've been championing #2 for the last several weeks I obviously
wouldn't object to that solution either, but I think #3 has far more
elegance.

"Resolving access to internal classes"

I'll abstain on this one because I don't feel qualified to weigh the issues
(ie I neither use nor write third-party dev tools).

Thanks Greg!

Steph

17 years ago by Josh Davis — view source — reply

unread

2008/10/15 Greg Beaver greg@chiaraquartet.net:

Read it and discuss.

Hello,

First of all I'd like to thank Greg for his efforts to move the
discussion in a positive direction. From a PHP user's point of view,
it's comforting to see that this kind of discussion can still take
place with a cool head and methodically.

I have a question about #1 and #2: aren't they functionally the same?
Based on current resolution rules (the ones used in the engine, not
the ones currently documented in the manual) it is my understanding
that there is only ever one namespace [resolution] operator and no
namespace separator, because there is no hierarchy in namespaces. The
"::" people use (myself included) to separate tokens in the
namespace's name are for decoration only (a "visual aid", as per the
old RFC) and they have no meaning. Therefore, users should be able to
use any number of consecutive colons in a namespace name, before the
namespace operator, just like we can use any number of consecutive
underscores in class names and anywhere else.

If the "::" contained in a namespace's name are separators, doesn't it
mean that namespaces are de facto nested? Which brings me back to the
current documentation, in which "new B::C" inside of namespace A would
create an instance of class C from namespace A::B, as opposed to the
current engine where it returns an instance of C from namespace B. I
don't know if I'm reading too much into it, but as a user, the
existence of "namespace separators" means to me that there multiple
namespaces and that they are nested and it leads me to expect the old
functionality (instance of A::B::C). Since that's not the case
anymore, I wouldn't expect the number of consecutive ":" to be
limited, making #1 and #2 the same. In fact, I wouldn't expect colons
to be authorized in namespace names at all.

Hoping I'm not opening a can of worms :)

JD

17 years ago by Alexey Zakhlestin — view source — reply

unread

Hi,

http://wiki.php.net/rfc/namespaceissues

solution #3: +1
change of resolving order: +1

--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

17 years ago by Derick Rethans — view source — reply

unread

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

In short:

I'm for option #1 - and I would have to disagree with "con 1" there --
we shouldn't give a damn about what people did with unreleased code.

As for the internal classes resolving, I am not too keen on slowing down
internal classes access. Obviously, this is only going to be ab issue if
you use namespaces though. The bad thing I find about it is that this
resolving is done during runtime -- but I suppose that'd happen anyway
because of autoload().

A bit on the reasoning against option #2: Option #2 introduces a new
concept yet again. Namespaces are already a new concept, and trying to
make it even more confusing wouldn't serve anybody.

regards,
Derick

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

17 years ago by Vesselin Kenashkov — view source — reply

unread

Thank you, Greg, for your efforts.

My vote:

+1 for 3)
+1 for the change in __autolod()

On Wed, Oct 15, 2008 at 11:35 PM, Greg Beaver greg@chiaraquartet.netwrote:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

--

--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com

17 years ago by Lars Strojny — view source — reply

unread

Hello Greg,

Am Mittwoch, den 15.10.2008, 15:35 -0500 schrieb Greg Beaver:
[...]

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Thanks for your efforts to fixing the remaining small issues with the
current implementation. We wrote 50.000 LOC against 5.3 since half a
year and I have to say the problems are minimal in the real world. But I
understand the issues, especially the way how classnames are resolved
are hard to guess. So +1 for your resolving proposal.

The usage issue is not that easy for as I have a conflict of interests
here: the lazy me votes for option 2 (no change for my code, ugly for
those who use functions, which we don't do anyway), the one who weights
whats best for PHP weights for option 3. So, the heck, let's do option
3, replacing "use Foo::Bar" with "use namespace Foo::Bar" is not that
hard.

Thanks for your solution!
Lars

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

17 years ago by Karsten Dambekalns — view source — reply

unread

Hi Greg, everyone.

Greg Beaver wrote:

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Oh, yeah, absolutely!

"Conflict between namespaced functions and static class methods"

I would prefer #1, but am equally happy with #3.

Note: Rewriting what we currently have to make it work with changes in
namespaces would be something we happily attack as soon as we know the
direction.

"Resolving access to internal classes"

Great.

And the autoload-for-internal classes issue would be no issue if (like
we currently do) one explicitly refers to them like "::Exception" anyway.

Regards,
Karsten

PS: We are still in Berlin at a TYPO3 core developer meeting, and I am
happy to see this issue (almost) resolved. The same is true for the
others here. Long live PHP!

17 years ago by Jochem Maas — view source — reply

unread

Greg Beaver schreef:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

well quite (although removal seems to me better than releasing without
tackling the technical issues [those you documented in your latest RFC] ...
but that's just me).

so far as my +1 - I give my vote to Greg's preferred solution(s) (Greg get
to vote with a +2 :-) ... I don't say this lightly, I've been convinced on-list
and off- by detailed arguments and stacks of example code that Greg really has
thought this through more than anyone else and what he offers is better than
anything anybody else has brought to the table (regarding the issues highlighted
in his last RFC)

rgds,
Jochem

Greg

17 years ago by Richard Quadling — view source — reply

unread

2008/10/15 Greg Beaver greg@chiaraquartet.net:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

With regard to accessing internal classes within a namespace, would
using the namespace separator be enough?

namespace blah;
function __autoload($class)
{
include $class . '.php';
}
$a = new Exception('hi'); // Internal
$b = new :::Execption('lo'); // Namespaced

It seems that it is up to me as the userland develop to explicitly
identify namespaces vs classes (I like :::), so I would have though
I'd need to deal with this when I want to call my namespaced class vs
a built in class.

Autoload would only get called if the correctly identified namespaced
class wasn't already present. If I said use the built in class, then
so be it.

OOI, would __autoload get "blah:::Exception" or just "Exception" ? If
the latter, how would I differentiate?

--

Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

17 years ago by Justin Carlson — view source — reply

unread

+1 for option 3, http://wiki.php.net/rfc/namespaceissues

Really don't want to see option 2.

Richard Quadling wrote:

2008/10/15 Greg Beaver greg@chiaraquartet.net:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

17 years ago by James Dempster — view source — reply

unread

If I understand correctly I vote.

+1 for Issue 1 option 1
+1 for Issue 2

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

17 years ago by Christian Schneider — view source — reply

unread

+1 for option 3 too (http://wiki.php.net/rfc/namespaceissues)

Chris

17 years ago by Ben Ramsey — view source — reply

unread

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

+1 for #3

--
Ben Ramsey
http://benramsey.com/

17 years ago by Ron Rademaker — view source — reply

unread

Greg Beaver wrote:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

+1 on #3

17 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in

I think it would be better if we had limited number of variants. We have
many people here with all kinds of opinions, but the thing is we need to
choose ONE way and no more. So I'd propose to cut some options,
otherwise I suspect some people would be discouraged by too many
options, or we get equal distribution between many of them and will get
nowhere.

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

17 years ago by Steph Fox — view source — reply

unread

Hi Stas,

I think it would be better if we had limited number of variants. We have
many people here with all kinds of opinions, but the thing is we need to
choose ONE way and no more. So I'd propose to cut some options, otherwise
I suspect some people would be discouraged by too many options, or we get
equal distribution between many of them and will get nowhere.

Actually we're down to 2 options at this stage: #1 or #3. Mostly it's PHP
users rather than devs doing the voting, but it's become obvious that
options #2 and #4 are very unpopular with them - and that simplicity is a
major element here.

Steph

17 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

http://wiki.php.net/rfc/namespaceissues

My opinion for the proposals:
A. I'm ok with use namespace, but it is inferior to the -> proposal.
While it allows explicit disambiguation, it does not allow to call both
in the same file. I'm not sure it's too much of a problem but

B. There's a huge problem with this proposal which you seem consistently
to ignore despite all my attempts to explain it. Failed autoload on each
call is BAD. Very bad. It is not cacheable, it leads to multiple disk
accesses and it is absolutely undetectable to the PHP user without the
use of special tools. So making all existing code contain this
performance bomb unless you rewrite it is very bad. It's better to have
this code fail and provide simple script to fix it in automatic fashion.
The fix you propose - writing use's - is not enough because as you noted
later inertia would make users not to use this code and thus have huge
performance hit - which most of them even wouldn't know where it came from.
I talked to many OO developers and most of them were OK with using :: on
internal classes when using namespaces.

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

17 years ago by Lukas Kahwe Smith — view source — reply

unread

B. There's a huge problem with this proposal which you seem
consistently to ignore despite all my attempts to explain it. Failed
autoload on each call is BAD. Very bad. It is not cacheable, it
leads to multiple disk accesses and it is absolutely undetectable to
the PHP user without the use of special tools. So making all
existing code contain this performance bomb unless you rewrite it is
very bad. It's better to have this code fail and provide simple
script to fix it in automatic fashion. The fix you propose - writing
use's - is not enough because as you noted later inertia would make
users not to use this code and thus have huge performance hit -
which most of them even wouldn't know where it came from.

first up i am a bit irritated by the use of the term "internal class",
i guess you both mean to say "class in the global namespaces"?

I talked to many OO developers and most of them were OK with
using :: on internal classes when using namespaces.

second, we are not talking an issue where prepending with a double
colon solves the issue, since example was about a case where i want to
autoload a file that defines a class in the current namespace and not
fall back to the global namespace.

however your performance concerns are quite valid.

imho the thing is, that the person who is developing a namespace that
is autoloadable knows this (or should know this), as a result its his
obligation to either trigger the autoload via a "use" statement or by
prepending the current namespace name to the class name.

imho the main use for namespaced code will be libraries and not
application level code (with the exception that some people have
mentioned that they might want to stick their templates in
namespaces), so i think this burden is legit, since most of us spend
their time writing application level code and not library code (sorry
full time ezc/zf developers).

so imho the solution is "none of the above". the solution is that
however wants to make his namespaced code to be autoloadable must make
sure he explicitly triggeres the autoloading.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

17 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

first up i am a bit irritated by the use of the term "internal class", i
guess you both mean to say "class in the global namespaces"?

I can't tell what Greg meant for him, but for me the problem exists
regardless of the class being internal or not.

imho the thing is, that the person who is developing a namespace that is
autoloadable knows this (or should know this), as a result its his
obligation to either trigger the autoload via a "use" statement or by
prepending the current namespace name to the class name.

Namespaces aren't autoloadable, classes are. But what I see happening is
that people would start converting excisting code, and since they are
human they will inevitable forget or miss class here and there. And it
would work, and pass all tests, and look fine and dandy on the outside -
but under the water it would contain the performance bomb of
non-cacheable exhaustive autoload search. It is a big disservice for our
users to put them into this situation where you need to be an expert to
even notice where the problem is - especially that we already know the
problem exists and we know how to fix it. Why not just fix it?

imho the main use for namespaced code will be libraries and not
application level code (with the exception that some people have
mentioned that they might want to stick their templates in namespaces),
so i think this burden is legit, since most of us spend their time
writing application level code and not library code (sorry full time
ezc/zf developers).

That doesn't matter - applications would contain private libraries as
part of the function, which would contain namespaces. Look at big
application like Magento - there's definitely potential for huge use of
namespaces inside the application. Namespaces aren't by no means limited
to off-the-shelf libraries - I see much use of them precisely in the
custom code in big projects.

But the more important issue here is that we KNOW there's a problem. Why
should we look for reasons to diminish its importance when we have a fix
for it, which most of the target audience would accept?

so imho the solution is "none of the above". the solution is that
however wants to make his namespaced code to be autoloadable must make
sure he explicitly triggeres the autoloading.

There's no such thing as "autoloadable" or "not autoloadable" code in
PHP now. So I'm afraid I miss what you trying to tell - do you say we
should stay with what we have now? Or do something else?

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

17 years ago by Greg Beaver — view source — reply

unread

Stanislav Malyshev wrote:

Namespaces aren't autoloadable, classes are. But what I see happening
is that people would start converting excisting code, and since they
are human they will inevitable forget or miss class here and there.
And it would work, and pass all tests, and look fine and dandy on the
outside - but under the water it would contain the performance bomb of
non-cacheable exhaustive autoload search. It is a big disservice for
our users to put them into this situation where you need to be an
expert to even notice where the problem is - especially that we
already know the problem exists and we know how to fix it. Why not
just fix it?

Hi Stas,

Was your proposal to do this for name resolution:

<?php
namespace blah;
$a = new Exception;

if for blah::Exception exists, use it
try to autoload blah::Exception
fail

instead of having the internal resolution? I would support this, and am
sorry if I mischaracterized your proposal in solution to issue #2. I
really thought I was proposing the thing you all worked out at ZendCon,
it was a simple misunderstanding on my part.

Greg

17 years ago by Nathan Rixham — view source — reply

unread

great work - just one little note that may/may not help..

after much more thought I think you're option #2 is actually best
however the choice of ":::" separator in the example really confuses
things and makes at an instant turn off..

I honestly think that if the option was rewritten as let's say:
one::step:>two()
one:>step::two()
(or indeed any other double-char operator) then it would make a lot more
sense, visually, logically and perhaps be the winner here..

Regards and thanks for the massive amount of patience :-)

17 years ago by Steph Fox — view source — reply

unread

after much more thought I think you're option #2 is actually best however
the choice of ":::" separator in the example really confuses things and
makes at an instant turn off..

This concept was originally presented using the ".." separator, and has been
presented with others since. The separator isn't the issue with option #2 so
much as that it's not a familar approach from other languages, and it's not
particularly intuitive either. I like #2 too, but it's become apparent from
the voting pattern that people really don't get it. We had a long discussion
on the list about this exact option using the ':::' separator earlier in the
week where many agreed to it in theory, but didn't actually recognise the
exact same proposal when they saw it on the wiki.

I think that pretty much disqualifies it as a solution for ns resolution in
PHP, sadly. If people on this list aren't able to fully grasp the concept,
it doesn't have a hope in user space.

Steph

17 years ago by Nathan Rixham — view source — reply

unread

Steph Fox wrote:

I think that pretty much disqualifies it as a solution for ns resolution
in PHP, sadly. If people on this list aren't able to fully grasp the
concept, it doesn't have a hope in user space.

agreed - one last little push can't hurt too much though can it?

17 years ago by Nathan Rixham — view source — reply

unread

Steph Fox wrote:

I think that pretty much disqualifies it as a solution for ns resolution
in PHP, sadly. If people on this list aren't able to fully grasp the
concept, it doesn't have a hope in user space.

agreed; one last little push can't hurt too much though can it?
(beats backtracking to ns vs packages or something ridiculous like that
<weg>)

17 years ago by Chris Stockton — view source — reply

unread

I have been watching the namespace conversations for months and I can not
get my head around this fixation on a new separator. Other languages get by
without separate resolution syntax, why not solve these ambiguities through
rules of precedence like everyone else? Throw possible ambiguity warnings if
we don't mind looking ahead for the performance hit and give users the
ability to alias their namespaces with AS when conflicts do occur they can
be easily fixed.
using BadNamedLib as BetterNamedLib;
using BadNamedLib;

Resolve using :: as a separator, have some simple rules and document them,
first namespace's loaded classes takes precedence over the last. Constansts
are more important then classes, or vice versa. Document the determined
precedence. Giving users a tool to alias namespaces solves a lot of the
namespace resolution issues.

Just my thoughts,

-Chris

17 years ago by Greg Beaver — view source — reply

unread

Chris Stockton wrote:

I have been watching the namespace conversations for months and I can not
get my head around this fixation on a new separator. Other languages get by
without separate resolution syntax, why not solve these ambiguities through
rules of precedence like everyone else? Throw possible ambiguity warnings if
we don't mind looking ahead for the performance hit and give users the
ability to alias their namespaces with AS when conflicts do occur they can
be easily fixed.
using BadNamedLib as BetterNamedLib;
using BadNamedLib;

Resolve using :: as a separator, have some simple rules and document them,
first namespace's loaded classes takes precedence over the last. Constansts
are more important then classes, or vice versa. Document the determined
precedence. Giving users a tool to alias namespaces solves a lot of the
namespace resolution issues.

Hi Chris,

This is actually option #3 on the list of solutions at
http://wiki.php.net/rfc/namespaceissues

Steph: can you catalog this as a vote for it?

Greg

17 years ago by Steph Fox — view source — reply

unread

Greg...

Hi Chris,

This is actually option #3 on the list of solutions at
http://wiki.php.net/rfc/namespaceissues

I know.

Steph: can you catalog this as a vote for it?

Not without Chris even looking at the options.

Steph

17 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

Was your proposal to do this for name resolution:

<?php
namespace blah;
$a = new Exception;

if for blah::Exception exists, use it

try to autoload blah::Exception

fail

Yes.

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

17 years ago by Greg Beaver — view source — reply

unread

Lukas Kahwe Smith wrote:

B. There's a huge problem with this proposal which you seem
consistently to ignore despite all my attempts to explain it. Failed
autoload on each call is BAD. Very bad. It is not cacheable, it leads
to multiple disk accesses and it is absolutely undetectable to the
PHP user without the use of special tools. So making all existing
code contain this performance bomb unless you rewrite it is very bad.
It's better to have this code fail and provide simple script to fix
it in automatic fashion. The fix you propose - writing use's - is not
enough because as you noted later inertia would make users not to use
this code and thus have huge performance hit - which most of them
even wouldn't know where it came from.

first up i am a bit irritated by the use of the term "internal class",
i guess you both mean to say "class in the global namespaces"?
no, we are talking about classes built into PHP such as Exception or
ArrayObject, not userspace classes without namespace.

Greg

17 years ago by Lukas Kahwe Smith — view source — reply

unread

Lukas Kahwe Smith wrote:

B. There's a huge problem with this proposal which you seem
consistently to ignore despite all my attempts to explain it. Failed
autoload on each call is BAD. Very bad. It is not cacheable, it
leads
to multiple disk accesses and it is absolutely undetectable to the
PHP user without the use of special tools. So making all existing
code contain this performance bomb unless you rewrite it is very
bad.
It's better to have this code fail and provide simple script to fix
it in automatic fashion. The fix you propose - writing use's - is
not
enough because as you noted later inertia would make users not to
use
this code and thus have huge performance hit - which most of them
even wouldn't know where it came from.

first up i am a bit irritated by the use of the term "internal
class",
i guess you both mean to say "class in the global namespaces"?
no, we are talking about classes built into PHP such as Exception or
ArrayObject, not userspace classes without namespace.

why are they different?
also since they apparently are different, how does this all work when
its not about an internal class, but a global useland class? as in
what if in your example it would not be the Exception class, but a
class called FooBar, which is defined in the global namespace in some
userland code?

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

17 years ago by Greg Beaver — view source — reply

unread

Lukas Kahwe Smith wrote:

Lukas Kahwe Smith wrote:

B. There's a huge problem with this proposal which you seem
consistently to ignore despite all my attempts to explain it. Failed
autoload on each call is BAD. Very bad. It is not cacheable, it leads
to multiple disk accesses and it is absolutely undetectable to the
PHP user without the use of special tools. So making all existing
code contain this performance bomb unless you rewrite it is very bad.
It's better to have this code fail and provide simple script to fix
it in automatic fashion. The fix you propose - writing use's - is not
enough because as you noted later inertia would make users not to use
this code and thus have huge performance hit - which most of them
even wouldn't know where it came from.

first up i am a bit irritated by the use of the term "internal class",
i guess you both mean to say "class in the global namespaces"?
no, we are talking about classes built into PHP such as Exception or
ArrayObject, not userspace classes without namespace.

why are they different?
also since they apparently are different, how does this all work when
its not about an internal class, but a global useland class? as in
what if in your example it would not be the Exception class, but a
class called FooBar, which is defined in the global namespace in some
userland code?

That's a great question, and I didn't realize it was a confusion, so
I'll try to answer it clearly.

The purpose behind resolution rules in namespaces is to make it easiest
to access

stuff with the same namespace prefix
internal functions, constants, and classes built into PHP

So, there is no chance for conflict with this code:

foo.php:
<?php
function __autoload($class){include $class . '.php';}
class Foobar{}
?>

<?php
namespace bar;
include 'foo.php';
$a = new Foobar; // this tries to autoload bar::Foobar if internal class
Foobar does not exist
?>

To force resolution to userspace Foobar, all you need add is:

<?php
use ::Foobar;
?>

Greg

17 years ago by Greg Beaver — view source — reply

unread

Stanislav Malyshev wrote:

Hi!

http://wiki.php.net/rfc/namespaceissues

My opinion for the proposals:
A. I'm ok with use namespace, but it is inferior to the -> proposal.
While it allows explicit disambiguation, it does not allow to call
both in the same file. I'm not sure it's too much of a problem but

Hi,

It does not allow calling both with the same import name, but it does allow:

<?php
namespace blah;
include 'thing1.php';
include 'thing2.php';
use class ::foo;
use namespace ::foo as another;

foo::blah(); // static method
another::blah(); // namespace function
?>

Greg

17 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

It does not allow calling both with the same import name, but it does allow:

<?php
namespace blah;
include 'thing1.php';
include 'thing2.php';
use class ::foo;
use namespace ::foo as another;

foo::blah(); // static method
another::blah(); // namespace function
?>

It's basically the same that my proposal does, only you have to work
twice as hard (two use's) and remember which name you assigned to what -
and you still would have to rewrite the code to use another:: - so you
have to both add use's and rewrite the actual call code. And you'd
have to do it even if names in class foo have nothing to do with names
in namespace foo.

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

17 years ago by Steph Fox — view source — reply

unread

Hey Stas,

It's basically the same that my proposal does, only you have to work twice
as hard (two use's) and remember which name you assigned to what - and you
still would have to rewrite the code to use another:: - so you have to
both add use's and rewrite the actual call code. And you'd have to do it
even if names in class foo have nothing to do with names in namespace foo.

Yes, but most times when there is conflict it will be between two sets of
code. So importing someone else's namespace explicitly and giving it a new
name is a good call IMHO.

Greg, you have questions outstanding on-list (mostly from Stas). Please
respond to them?

nb Stas - I asked the same question about warnings, Greg updated his
proposal since then to answer it.

Steph

17 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

Yes, but most times when there is conflict it will be between two sets
of code. So importing someone else's namespace explicitly and giving it
a new name is a good call IMHO.

If you have two distinct sets of code, why you use same namespace for
both of them? Namespaces are specifically designed so you could have
different sets of code in different places.

nb Stas - I asked the same question about warnings, Greg updated his
proposal since then to answer it.

As it is now, every call to class::method() not accompanied with use
should produce E_WARNING. I do not think it is an acceptable situation -
this would make code migration a nightmare, since even if you never use
functions and never even have any chance for a conflict, you still have
to insert hundreds of imports into your code, just to shut up the
warnings. I don't think it is a good idea. Feature that you do not need,
can not disable and have to work around is called "bug".

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

17 years ago by Steph Fox — view source — reply

unread

Hi Stas,

If you have two distinct sets of code, why you use same namespace for both
of them? Namespaces are specifically designed so you could have different
sets of code in different places.

I was unclear there, sorry. I was thinking of the situation where 'I use a
class that happens to have the same name as the namespace in a third-party
lib I need to use in my application'.

nb Stas - I asked the same question about warnings, Greg updated his
proposal since then to answer it.

As it is now, every call to class::method() not accompanied with use
should produce E_WARNING.

? That's certainly not how I read it.

I do not think it is an acceptable situation - this would make code
migration a nightmare, since even if you never use functions and never
even have any chance for a conflict, you still have to insert hundreds of
imports into your code, just to shut up the warnings. I don't think it is
a good idea. Feature that you do not need, can not disable and have to
work around is called "bug".

Can we double-check this?

Steph

17 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

I was unclear there, sorry. I was thinking of the situation where 'I use
a class that happens to have the same name as the namespace in a
third-party lib I need to use in my application'.

Why would you do that? I.e. suppose there's library having namespace
Zend::Controller::Action::Plugin - why would your name your class
Zend::Controller::Action::Plugin and not Steph::Controller::Action::Plugin?

As it is now, every call to class::method() not accompanied with use
should produce E_WARNING.

? That's certainly not how I read it.

That's what is says:

If the "use" statement is missing, an `E_WARNING` should also be thrown to
alert the user to the ambiguity

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

17 years ago by Steph Fox — view source — reply

unread

Why would you do that? I.e. suppose there's library having namespace
Zend::Controller::Action::Plugin - why would your name your class
Zend::Controller::Action::Plugin and not
Steph::Controller::Action::Plugin?

Why do you assume all third-party software is going to be ZF? Or that code
is going to be written around third-party software in the first place,
rather than some useful lib that doesn't even exist yet might be slotted
into an app 3 or 10 years from now?

As it is now, every call to class::method() not accompanied with use
should produce E_WARNING.

? That's certainly not how I read it.

That's what is says:

If the "use" statement is missing, an E_WARNING should also be thrown to
alert the user to the ambiguity

I assume that's only if there is ambiguity, but I'm not in a position to
test the patch right now so can't say authoritatively (@Greg: speak!)

but Stas - conceptually you aren't a million miles apart in the first place,
so if you're finding that in your tests maybe helping figure a way through
would be more productive. Greg complains that your version gives no
warnings, you complain that Greg's version gives too many... please, guys,
can you work together?

Steph

17 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

Why do you assume all third-party software is going to be ZF? Or that

Are you familiar with the concept of "example"?

code is going to be written around third-party software in the first
place, rather than some useful lib that doesn't even exist yet might be
slotted into an app 3 or 10 years from now?

Useful lib would have its own namespace and you would have your own.

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

17 years ago by Steph Fox — view source — reply

unread

Useful lib would have its own namespace and you would have your own.

The assumption to date has been that most userspace code wouldn't use
namespaces. Libraries and plugins would be more likely to use them. Ie the
chance of a ns/class collision isn't likely to be so much under the control
of the application developer as your example posits.

Steph

17 years ago by Gregory Beaver — view source — reply

unread

Stanislav Malyshev wrote:

Hi!

Yes, but most times when there is conflict it will be between two
sets of code. So importing someone else's namespace explicitly and
giving it a new name is a good call IMHO.

If you have two distinct sets of code, why you use same namespace for
both of them? Namespaces are specifically designed so you could have
different sets of code in different places.

nb Stas - I asked the same question about warnings, Greg updated his
proposal since then to answer it.

As it is now, every call to class::method() not accompanied with use
should produce E_WARNING. I do not think it is an acceptable situation

this would make code migration a nightmare, since even if you never
use functions and never even have any chance for a conflict, you still
have to insert hundreds of imports into your code, just to shut up the
warnings. I don't think it is a good idea. Feature that you do not
need, can not disable and have to work around is called "bug".
Hi Stas,

This is not what is proposed. The E_WARNING is only on a name
conflict. Please re-read or try the patch:

http://pear.php.net/~greg/resolve_conflict.patch.txt

Greg

17 years ago by Arvids Godjuks — view source — reply

unread

+1 on #3 (I really was for option #2, but #3 seems to be more elegant).

As I remember this is a voting thread, but most of you started to argue
again and trashed the thread. Please stop doing that.

17 years ago by Stefan Walk — view source — reply

unread

On Friday 17 October 2008 04:02:32 Gregory Beaver wrote:

Hi Stas,

This is not what is proposed. The E_WARNING is only on a name
conflict. Please re-read or try the patch:

http://pear.php.net/~greg/resolve_conflict.patch.txt

Greg

Any particular reason why it defaults to seeing it as a namespace member
function and not as a static method call? I'd guess it "guesses wrong" more
often this way.

Regards,
Stefan

17 years ago by Greg Beaver — view source — reply

unread

Stefan Walk wrote:

On Friday 17 October 2008 04:02:32 Gregory Beaver wrote:

Hi Stas,

This is not what is proposed. The E_WARNING is only on a name
conflict. Please re-read or try the patch:

http://pear.php.net/~greg/resolve_conflict.patch.txt

Greg

Any particular reason why it defaults to seeing it as a namespace member
function and not as a static method call? I'd guess it "guesses wrong" more
often this way.

It avoids autoload attempts for namespace functions.

Greg

17 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

This is not what is proposed. The E_WARNING is only on a name
conflict. Please re-read or try the patch:

http://pear.php.net/~greg/resolve_conflict.patch.txt

I see the patch is doing zend_fetch_class, which autoloads. So
autoloading on each call to namespace function?

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

17 years ago by Greg Beaver — view source — reply

unread

Stanislav Malyshev wrote:

Hi!

This is not what is proposed. The E_WARNING is only on a name
conflict. Please re-read or try the patch:

http://pear.php.net/~greg/resolve_conflict.patch.txt

I see the patch is doing zend_fetch_class, which autoloads. So
autoloading on each call to namespace function?

yes - unless a user explicitly "use namespace blah;"

This would require namespace function users to do a little extra legwork
at the top of the file, which would then guarantee that class users'
code does not change behavior without warning.

Greg

17 years ago by Josh Davis — view source — reply

unread

I have a question about 3. Where in a script can you use the "use"
statement? Could it be used inside conditionals? For example,

if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}

If that's the case, could we have a word from an opcode cache guru
about how nice it would play with them?

Also, could you please give us a couple of examples of code that would
trigger the E_WARNING mentionned in case of ambiguity and how that
ambiguity would be resolved? Thanks in advance.

JD

17 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}

No, I don't think this would work since use is compile-time statement.

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

17 years ago by Greg Beaver — view source — reply

unread

Stanislav Malyshev wrote:

Hi!

if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}

No, I don't think this would work since use is compile-time statement.
use is also a top_statement, which means it cannot be inside {} at all.

Greg

17 years ago by Karsten Dambekalns — view source — reply

unread

Hi.

Sorry for yet another OT post in this thread.

Josh Davis wrote:

I have a question about 3. Where in a script can you use the "use"
statement? Could it be used inside conditionals? For example,

if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}

I hope this is a badly chosen example, as code should never behave
seperately when under test as compared to production. Use dependency
injection to feed a mock object, but don't do this.

Regards,
Karsten

17 years ago by Scott MacVicar — view source — reply

unread

Greg Beaver wrote:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

I'd much rather see ::: used and don't care too much about those with
code already written, we never guarantee BC on unreleased versions.

Though I don't object to #3 at all either, so indifferent!

Regarding internal class resolving, it seems logical but will slow down
resolution within namespaces. But I doubt this is much of an issue as it
doesn't affect those not using namespaces.

Scott

17 years ago by Steph Fox — view source — reply

unread

Heya Scott,

I'd much rather see ::: used and don't care too much about those with
code already written, we never guarantee BC on unreleased versions.

Well, that narrows it down to #1 or #2.

Though I don't object to #3 at all either, so indifferent!

OK, so we have #1, #2 or #3 now from you. What should I put down as your
primary vote?

Regarding internal class resolving, it seems logical but will slow down
resolution within namespaces. But I doubt this is much of an issue as it
doesn't affect those not using namespaces.

This appears to have been resolved between the two (and everybody else) now.
Greg and Stas actually want the same thing here, they just misunderstood one
another. (@Greg, @Stas: correct me if I'm wrong.)

Steph

17 years ago by Scott MacVicar — view source — reply

unread

Heya Scott,

I'd much rather see ::: used and don't care too much about those with
code already written, we never guarantee BC on unreleased versions.

Well, that narrows it down to #1 or #2.

Though I don't object to #3 at all either, so indifferent!

OK, so we have #1, #2 or #3 now from you. What should I put down as
your primary vote?

#1 and then #3.

Regarding internal class resolving, it seems logical but will slow
down
resolution within namespaces. But I doubt this is much of an issue
as it
doesn't affect those not using namespaces.

This appears to have been resolved between the two (and everybody
else) now. Greg and Stas actually want the same thing here, they
just misunderstood one another. (@Greg, @Stas: correct me if I'm
wrong.

Scott

17 years ago by Steph Fox — view source — reply

unread

#1 and then #3.

Thanks :)

Steph

17 years ago by Nathan Rixham — view source — reply

unread

Steph Fox wrote:

#1 and then #3.

Thanks :)

Steph

that is so wrong, you know 3 was better - you're not in my club :'(

17 years ago by Steph Fox — view source — reply

unread

that is so wrong, you know 3 was better - you're not in my club :'(

Sorry to disappoint, but I'm collecting votes here, not making them up as I
go along.

Steph

17 years ago by Nathan Rixham — view source — reply

unread

Steph Fox wrote:

that is so wrong, you know 3 was better - you're not in my club :'(

Sorry to disappoint, but I'm collecting votes here, not making them up
as I go along.

Steph

twas directed at scott; an i typo'd n meant 3, and was misplaced humour

tis 2am here and I really shouldn't be on any lists or anywhere of
even vague importance - apologies!

17 years ago by Stan Vassilev | FM — view source — reply

unread

Regarding internal class resolving, it seems logical but will slow down
resolution within namespaces. But I doubt this is much of an issue as it
doesn't affect those not using namespaces.

I don't think that makes sense to say "it doesn't affect people not using
namespaces" when talking about namespace design.

I believe internal classes should be explicitly disambiguated, even if it
looks ugly, so the autoloader can occur at the right place in the chain.
Anything else would make namespace+autoload an unusable combination.

Greg, good work on the proposals but I think there's some confusion, even
among core devs about the nitty gritty details on some of the proposals. I'd
be nice if we can add "allowed / proper" and "not allowed / wrong" examples
and such to the RFC-s so it's more obvious what impact each proposal has on
code.

As for ::: vs ::, those are virtually not distinguishable in a lot of code,
so if that's to go, pick another syntax. ":>" is fine, "" is fine, ".." is
fine.

Regards, Stan Vassilev.

17 years ago by Larry Garfield — view source — reply

unread

On Wednesday 15 October 2008 3:35:11 pm Greg Beaver wrote:

Hi,

http://wiki.php.net/rfc/namespaceissues

For the first point, #1 but with a less eyestrain-causing separator than :::.
Easy for both humans and compilers to tell the difference at any point
without referring back to the top of the file. Yes that would still mean
existing namespace alpha code must be revised, but I look at that as "Thank
you for testing it and finding this design flaw now rather than after it was
released!" It's all in the delivery. :-)

For the second point, am I correct in my understanding that existing code that
doesn't use namespaces at all, under that setup, would not have the extra
autoload magically popup? It's just code that declares a namespace that
would have to also explicitly "use" its internal classes? If so, then +1
from me. If not, I'm undecided.

--
Larry Garfield
larry@garfieldtech.com

17 years ago by Benjamin Schulz — view source — reply

unread

+1 for #3 ("use namespace" or "use class")

Regards,
Benjamin

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

17 years ago by Ryan Panning — view source — reply

unread

Greg Beaver wrote:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

Issue A: #2

Issue B: Yes

The reason I like #2 is because it also helps with the autoload
confusion. It will clearly state that you are either looking for a class
or namespace file, by looking for the element separator. However, I
think :> or something other than ::: would be a better separator, for
better visability. Ex:

Request Autoload Gets Type

A::B:>C A::B:>C Class
A::B:>func() A::B Namespace
A::B:>C::CONST A::B:>C Class
A::B::C:>D::method() A::B::C:>D Class
A::B::C::D:>CONST A::B::C::D Namespace

Question for issue B, will the change only effect class requests? Or
would it also trigger autoload for function requests (thinking it's a
namespace request)? I could see that being a problem as 90% of function
requests are for internal functions and ::func() for everything would be
a pain.

Similar goes for namespace function/const requests. At this point it
wouldn't be a big deal but lets say core internal functions are migrated
to namespaces (ex: Array::map()). Does that trigger autoload before it
finds the internal Array::map()? I'm thinking that's where option #3
comes into play, but "using .." every internal class/ns/func would also
be a pain.

Sorry if this was already answered, I've been trying to keep up. :)

17 years ago by Nate Tallman — view source — reply

unread

+1 #3

Greg Beaver wrote:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

Issue A: #2

Issue B: Yes

The reason I like #2 is because it also helps with the autoload confusion.
It will clearly state that you are either looking for a class or namespace
file, by looking for the element separator. However, I think :> or something
other than ::: would be a better separator, for better visability. Ex:

Request Autoload Gets Type

A::B:>C A::B:>C Class
A::B:>func() A::B Namespace
A::B:>C::CONST A::B:>C Class
A::B::C:>D::method() A::B::C:>D Class
A::B::C::D:>CONST A::B::C::D Namespace

Question for issue B, will the change only effect class requests? Or would
it also trigger autoload for function requests (thinking it's a namespace
request)? I could see that being a problem as 90% of function requests are
for internal functions and ::func() for everything would be a pain.

Similar goes for namespace function/const requests. At this point it
wouldn't be a big deal but lets say core internal functions are migrated to
namespaces (ex: Array::map()). Does that trigger autoload before it finds
the internal Array::map()? I'm thinking that's where option #3 comes into
play, but "using .." every internal class/ns/func would also be a pain.

Sorry if this was already answered, I've been trying to keep up. :)

17 years ago by pstradomski@gmail.com — view source — reply

unread

W liście Ryan Panning z dnia piątek 17 października 2008:

Request Autoload Gets Type

A::B:>C A::B:>C Class
A::B:>func() A::B Namespace
A::B:>C::CONST A::B:>C Class
A::B::C:>D::method() A::B::C:>D Class
A::B::C::D:>CONST A::B::C::D Namespace

I'm just a mere user, but if we go for other namespace separator (be it :::
or :> or anything else), then I'd rather see it used both between namespace
and class/function/constant name and between namespace parts. To be clear -
for the examples above I'd rather have them written as:

A:>B:>C
A:>B:>func()
A:>B:>C::CONST
A:>B:>C:>D::method()

or A:::B:::C, A:::B:::func, A:::B:::C::CONST.

That way :: is just operator for static class access (static methods and
properties), while :> or ::: is just namespace access operator, so we can
always assume that anything on the left side of ::: or :> is a namespace. In
Ryan's version :: is sometimes static class access operator, sometimes
namespace segment separator, depending on position.

--
Paweł Stradomski

17 years ago by Ryan Panning — view source — reply

unread

Paweł Stradomski wrote:

W liście Ryan Panning z dnia piątek 17 października 2008:

Request Autoload Gets Type

A::B:>C A::B:>C Class
A::B:>func() A::B Namespace
A::B:>C::CONST A::B:>C Class
A::B::C:>D::method() A::B::C:>D Class
A::B::C::D:>CONST A::B::C::D Namespace

I'm just a mere user, but if we go for other namespace separator (be it :::
or :> or anything else), then I'd rather see it used both between namespace
and class/function/constant name and between namespace parts. To be clear -
for the examples above I'd rather have them written as:

A:>B:>C
A:>B:>func()
A:>B:>C::CONST
A:>B:>C:>D::method()

or A:::B:::C, A:::B:::func, A:::B:::C::CONST.

That way :: is just operator for static class access (static methods and
properties), while :> or ::: is just namespace access operator, so we can
always assume that anything on the left side of ::: or :> is a namespace. In
Ryan's version :: is sometimes static class access operator, sometimes
namespace segment separator, depending on position.

That would be #1 in the options. I thought about that but then the
autoloader would get exactly the same input as it does now, just with a
different separator. To truly help the user make an autoloader that
knows what it should be loading you must separate class from namespace
request. The parser should know what to string to send to the autoloader by:

Namespace:
Element after the element separator is a CONSTANT or function(). Ex:
$func = A::B::C:>func();
$const = A::B::C:>CONST;

Class:
Element after the element separator is a class CONSTANT or static method
or it is a "new" request. Basically if there is :: after the element
separator. Ex:
$method = A::B:>C::method();
$cconst = A::B:>C::CONST;

Just to note, the below could be viewed as a namespace request. However,
because it's a "new"/construct request we know that it's a class.
$obj = new A::B:>C;
$obj = new A::B:>C();

Note, this option has lost in the voting already. Although I think this
issue will come up at a later point anyway.

Also, in Greg's wiki, for option #2, I don't see how it's possible to
Get::Any::Deeper:>Than::THIS = Class Constant
It::Just::Does:>Not::Seem:>POSSIBLE = Namespace Constant of?
This::Could::Vary:>Well::$Be::POSSIBLE = Class Const of Static Class Var

17 years ago by Steph Fox — view source — reply

unread

I'm just a mere user, but if we go for other namespace separator (be it
::: or :> or anything else), then I'd rather see it used both between
namespace and class/function/constant name and between namespace parts.

OK, so maybe I should explain one little thing about the significance of
those results: we don't need a namespace separator.

74% of those voters either actively requested or said they could live with
Greg's option #3. Now, the philosophy that separates that option from Greg's
other proposals is that it doesn't try to avoid conflict; it accepts that
there will be ambiguity, and then tries to deal with it.

This is also the approach Stas' proposals take.

No more namespace separator arguments, ever. It was worth it :)

Steph

17 years ago by Marcus Boerger — view source — reply

unread

Hello Greg,

Many thanks for wirting a nice proposal. Now, I consider #2 and #4 as
no options, just as most everyone else. Regarding #3, I see it
contradicting our KISS approach. You can actually write code where an
Identifier in two scripts that share the same includes mean something
completely different. Please not. Your #1 is actually my number 1 and I
said so about 5 years ago in the first napesace implementation. And I
said so over a year ago. I like #1 because it is easier, conflict free
by design and does not have any issue with __autoload or whatever.

In your RFC you write under con 2, that there are issues with missing
triple colons. However for the most cases the users are safe. Especially
in code like you are showing the compiler can tell that it must be wrong.
That is you can only have on double colon on the right and no other one
left of that. And if this is still too problematic we could even make it
a quad colon. That should be easy enough to read.

Besides the above I think our users want 'use' in their if clauses. And
we have to consider that. Technically we can easily allow use in the main
block outside functions. But that will interfere with compiler caches. So
as practical that might be, I think we should not really do it. And if at
some later point in time we think it is absolutely necessary we can at it
in PHP 10 or whatever.

Next I do not want any special treatment for internal classes at all!

If the user wants to hide the exception class then he has to derive the
original one that he finds in the main namespace:

<?php
namespace ShootInTheFoot;
use my_stupid_exception as Exception;
throw Exception;

Well the user wanted to and did:

<?php
namespace ShootInTheFoot;
class Exception extends :::Exception { }

Having use inside if gives us:

<?php
namespace MyApp;
if ($_GLOBALS['logging']) {
use MyLoggingException;
} else {
use :::Exception as Exception;
}
throw Exception; // Which loggs if I want to

However we already have if for includes. So the question is whether we
want to increase the mess (from a compiler caches point of view) or not.

just my $0.02

marcus

Wednesday, October 15, 2008, 10:35:11 PM, you wrote:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

Best regards,
Marcus

17 years ago by Jessie Hernandez — view source — reply

unread

Greg Beaver wrote:

Hi,

http://wiki.php.net/rfc/namespaceissues

Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?

Greg

Hi Greg,

I've read through the posts and the RFC and am not sure if this was
discussed before, but there is one other proposal I'd like to throw out
there: why not require all classes that are inside namespaces to be
explicitly imported? This would follow the AS3 approach
(http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/statements.html#import).

I believe this would solve the issue with the namespace separator at
compile-time. The namespace separator can be left as :: and would only
be used in certain cases, such as when creating objects dynamically
(i.e. <code>$c = 'MyNs::MyClass'; $o = new $c;</code>). The double-colon
would work dynamically, since at runtime you can tell what's a namespace
and what's a class.

So the class resolution rules would change to the following:

If the class was explicitly use'd, then use that class.
If not, look for the class in the global namespace (this would
include internal classes).

If one wanted to have a custom Exception class inside a namespace, one
would first alias the core Exception class and then extend from that:

<?php
use Exception as PhpException;

class Exception extends PhpException {}
?>

Thoughts, comments?

--

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

17 years ago by Jessie Hernandez — view source — reply

unread

Jessie Hernandez wrote:

Hi Greg,

I've read through the posts and the RFC and am not sure if this was
discussed before, but there is one other proposal I'd like to throw out
there: why not require all classes that are inside namespaces to be
explicitly imported? This would follow the AS3 approach
(http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/statements.html#import).

I believe this would solve the issue with the namespace separator at
compile-time. The namespace separator can be left as :: and would only
be used in certain cases, such as when creating objects dynamically
(i.e. <code>$c = 'MyNs::MyClass'; $o = new $c;</code>). The double-colon
would work dynamically, since at runtime you can tell what's a namespace
and what's a class.

So the class resolution rules would change to the following:

If the class was explicitly use'd, then use that class.

If not, look for the class in the global namespace (this would
include internal classes).

If one wanted to have a custom Exception class inside a namespace, one
would first alias the core Exception class and then extend from that:

<?php
use Exception as PhpException;

class Exception extends PhpException {}
?>

Thoughts, comments?

Adding to this, I would require all elements, not just classes, to be
use'd (this is also in line with AS3). This would allow functions and
constants to also be namespaced. Any use of :: at compile-time would be
used to separate a class from a member. For example, you could never use
MyNs::MyClass::myMethod, but since a "use" statement is required, you
would use MyClass::myMethod directly.

--

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

my last attempt at sanity with namespaces View as Markdown

Thanks for your solution! Lars

--

There's no such thing as "autoloadable" or "not autoloadable" code in PHP now. So I'm afraid I miss what you trying to tell - do you say we should stay with what we have now? Or do something else?

Yes.

If the "use" statement is missing, an E_WARNING should also be thrown to alert the user to the ambiguity

Useful lib would have its own namespace and you would have your own.

I see the patch is doing zend_fetch_class, which autoloads. So autoloading on each call to namespace function?

No, I don't think this would work since use is compile-time statement.

Request Autoload Gets Type

Request Autoload Gets Type

Request Autoload Gets Type

Request Autoload Gets Type

Thanks for your solution!
Lars

There's no such thing as "autoloadable" or "not autoloadable" code in
PHP now. So I'm afraid I miss what you trying to tell - do you say we
should stay with what we have now? Or do something else?

If the "use" statement is missing, an `E_WARNING` should also be thrown to
alert the user to the ambiguity

I see the patch is doing zend_fetch_class, which autoloads. So
autoloading on each call to namespace function?