Re: [PHP-DEV] my last attempt at sanity with namespaces
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
+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.
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
+1 for #3 (use namespace or use class) Regards, Benjamin On 15.10.2008, at 22:35, 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
On Thu, Oct 16, 2008 at 12:35 AM, Greg Beaver [EMAIL PROTECTED] wrote: Hi, http://wiki.php.net/rfc/namespaceissues solution #3: +1 change of resolving order: +1 -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] my last attempt at sanity with namespaces
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss.
Solution #1 is imho the best one to disambiguate everything, but the
readability problem is not to be overlooked. To keep this short, just
read the following rewrite of the lines for the problem code:
foo.php
?php
namespace one..step;
function two(){}
namespace one;
class step {
static function two(){}
}
?
main.php
?php
include 'foo.php';
one..step::two(); // clearly namespace one, static method on class step
one..step..two(); // clearly namespace one..step, function two
?
Addressing the cons for the ::: separator:
1. all existing namespace code must still be rewritten, sorry about
that.
2. this..example..with::slight..error..is..much..easier..to::see();
Two sequential dots currently produce a syntax error, so the
implementation doesn't have to worry about ambiguity or bc-issues.
Disclaimer: I have not written any namespaced php code yet (so I'm not
worried about con #1 ;-)).
Ciao, Marc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
On Wed, 15 Oct 2008, 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 [EMAIL PROTECTED]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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Vesselin Kenashkov developer at www.webstudiobulgaria.com
Re: [PHP-DEV] my last attempt at sanity with namespaces
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: [EMAIL PROTECTED] Weblog: http://usrportage.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
2008/10/15 Greg Beaver [EMAIL PROTECTED]:
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=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
+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 [EMAIL PROTECTED]: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
If I understand correctly I vote. +1 for Issue 1 option 1 +1 for Issue 2 On Wed, Oct 15, 2008 at 9:35 PM, Greg Beaver [EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
On 16.10.2008, at 17:37, Stanislav Malyshev 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? 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 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Lukas Kahwe Smith wrote: On 16.10.2008, at 17:37, Stanislav Malyshev 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
On 16.10.2008, at 18:59, Greg Beaver wrote: Lukas Kahwe Smith wrote: On 16.10.2008, at 17:37, Stanislav Malyshev 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 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Lukas Kahwe Smith wrote:
On 16.10.2008, at 18:59, Greg Beaver wrote:
Lukas Kahwe Smith wrote:
On 16.10.2008, at 17:37, Stanislav Malyshev 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
1) stuff with the same namespace prefix
2) 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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; 1) if for blah::Exception exists, use it 2) try to autoload blah::Exception 3) 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Hi! Was your proposal to do this for name resolution: ?php namespace blah; $a = new Exception; 1) if for blah::Exception exists, use it 2) try to autoload blah::Exception 3) fail Yes. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
On 17 Oct 2008, at 01:19, Steph Fox wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
#1 and then #3. Thanks :) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Steph Fox wrote: #1 and then #3. Thanks :) - Steph that is so wrong, you know 3 was better - you're not in my club :'( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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, On Wed, Oct 15, 2008 at 6:35 PM, Greg Beaver [EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: [EMAIL PROTECTED] URL: http://blog.bisna.com Rio de Janeiro - RJ/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Conflict Between Namespaced Functions and static class methods I think #3 (use namespace or use class) makes the most sense. I assume if there is a conflict without being explicit it would give an error? I also assume in the even of no conflict you can still just say use foo and will assume namespace, right? If so that seems to be very clear. Regarding the potential __autoload performance problem, how big are we talking? Resolving access to internal classes I think your suggestion of changing the order around makes perfect sense. All that said, I want to personally thank-you Greg for getting us to focus on the real issues, not the politics around it. --Tony - Original Message From: Greg Beaver [EMAIL PROTECTED] To: PHP Developers Mailing List internals@lists.php.net Sent: Wednesday, October 15, 2008 3:35:11 PM Subject: [PHP-DEV] my last attempt at sanity with namespaces 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
2008/10/15 Greg Beaver [EMAIL PROTECTED]: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
