Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Namespaces in PHP 6 - ++$take »

Namespaces in PHP 6 - ++$take

php.internals

Sean Coates

19 years ago
Hello all, A number of factors have come together to prompt me to possibly commit mailing-list-suicide by re-opening the namespace issue. Last week at Zendcon, a number of PHP developers/community members chatted about namespaces in PHP 6. That chat was the prime motivator for this email, but the recent (be they misguided) complaints about symbol collisions in DateTime, as well as blog entries such as Jeff Moore's on maintainability [1]. None of us chatting seemed to be able to come up with a good reason we don't yet have namespaces, other than frustration (the last time we discussed this, the thread became VERY long and drawn out), indecision (we couldn't seem to come to a decision on a suitable operator), and complacency. The way I see it is that implementing namespaces is a technical hurdle, and the reasons we haven't jumped it are political, not technical. So, let's deal with these 3 problems: Frustration: this thread will likely get long. Please avoid long-winded explanation of why you don't like the looks of "\" or how ":::" is hard to type. If you have something relevant to say, it's probably already been said [2][3]. Please review the archives. Indecision: We couldn't decide on "\" or ":::". What this comes down to is that "\" is the only remaining operator that can be typed in a single keystroke on us_en keyboards. The other choice was ":::". I, for one, am OK with either operator. I think someone with appropriate (social) karma needs to simply commit to one or the other, and we'll make do... we always do. Complacency: Most of the time, I'm happy to maintain the status quo in PHP-land. However, the lack of namespaces is causing more trouble than its absence is preventing. I think most PHP users would agree that namespaces are a welcome addition, and without them, PHP suffers. Let's take this in small steps and implement optional userspace namespacing. There's no need to dive head-first into this and make dramatic moves like putting all core functions into a PHP namespace. Baby steps, please. And, in conclusion (thanks for reading this far; I've certainly exceeded the average non-code-paste post length, a few times over), remember that the core devs discussed this in Paris, last year [4]. They didn't come to a conclusion (note the use of "if"), though. Let's settle this political issue, please, so we can get on to solving the technical issues that will inevitably crop up. S [1] http://www.procata.com/blog/archives/2006/11/09/why-is-php-code-considered-hard-to-maintain/ [2] http://beeblex.com/lists/index.php/php.internals/20586 [3] http://beeblex.com/lists/index.php/php.internals/17484 [4] http://php.net/~derick/meeting-notes.html#name-spaces

Ilia A.

19 years ago
On 10-Nov-06, at 11:51 AM, Sean Coates wrote:
> The way I see it is that implementing namespaces is a technical > hurdle, > and the reasons we haven't jumped it are political, not technical.
That's a bit of a circular logic no? There are indeed technical challenges to implementing namespaces, these reasons have been covered in previous discussions many times, since no adequate solution was devised they were never implemented. Once those issues are resolved or at the very least solutions are known, we can consider whether or not this is something that's truly needed.
> Complacency: Most of the time, I'm happy to maintain the status quo in > PHP-land. However, the lack of namespaces is causing more trouble than > its absence is preventing. I think most PHP users would agree that > namespaces are a welcome addition, and without them, PHP suffers. > Let's > take this in small steps and implement optional userspace namespacing. > There's no need to dive head-first into this and make dramatic moves > like putting all core functions into a PHP namespace. Baby steps, > please.
I think this is a bogus argument. In order to benefit from namespaces you need to use them, just like to benefit from containment through prefixing you need to prefix functions/classes/etc... Namespaces are not a magic bullet that will instantly make your problems go away and make your code better. If anything it'll make code complex and intertwined, introduce serious scope issue most people have not had to consider up until now and so on. It will without a doubt increase language complexity as well, which generally translates to a loss in performance. Ilia Alshanetsky

Sean Coates

19 years ago
> That's a bit of a circular logic no? There are indeed technical > challenges to implementing namespaces, these reasons have been covered > in previous discussions many times, since no adequate solution was > devised they were never implemented. Once those issues are resolved or > at the very least solutions are known, we can consider whether or not > this is something that's truly needed.
I think we got hung up on political issues. The last discussion was not technical (other than "no, you can't use ! -- it's already an operator). I'd love to move onto discussing the technical hurdles, but I don't think we came to a political conclusion, yet.
> I think this is a bogus argument. In order to benefit from namespaces > you need to use them, just like to benefit from containment through > prefixing you need to prefix functions/classes/etc... Namespaces are not > a magic bullet that will instantly make your problems go away and make > your code better. If anything it'll make code complex and intertwined, > introduce serious scope issue most people have not had to consider up > until now and so on. It will without a doubt increase language > complexity as well, which generally translates to a loss in performance.
I don't think namespaces are a magic bullet. As it stands, it's impossible to use namespaces without a third party patch that may or may not work. I strongly believe that if namespaces are implemented in PHP 6, most of our prefixing/symbol collisions will go away as people migrate. It's much easier to track down a failed import than to comment out a function declaration in the PHP source. I also don't deny that there will be a minor performance hit. There are a ton of other things in PHP that reduce performance.. the idea is to find a balance of which ones are worth it (as we did with OOP and Unicode), and I believe that namespaces are worth it. I also know that I'm not alone in this. S

Ilia A.

19 years ago
On 10-Nov-06, at 12:41 PM, Sean Coates wrote:
> I don't think namespaces are a magic bullet. As it stands, it's > impossible to use namespaces without a third party patch that may > or may > not work. I strongly believe that if namespaces are implemented in PHP > 6, most of our prefixing/symbol collisions will go away as people > migrate. It's much easier to track down a failed import than to > comment > out a function declaration in the PHP source.
PHP 6 is not yet out and probably won't be production quality for quite some time. Which means that migration to it en mass is probably not going to happen this decade :-). If we take 5.x adoption as a benchmark it took it over 2 years to even reach the 10% mark and big PHP apps still (with good reason) focus on the much larger PHP 4 market. Namespacing core classes/function would be a supremely bad idea as it could quite literally break every single application. You also need to consider that until PHP X attains at least 50% or more market penetration few people would be willing to write applications that require this version of PHP to work. This is why many of the projects and companies I am familiar still write new code in PHP 4 rather then in PHP 5, despite that version having numerous perceived advantages.
> I also don't deny that there will be a minor performance hit. There > are > a ton of other things in PHP that reduce performance.. the idea is to > find a balance of which ones are worth it (as we did with OOP and > Unicode), and I believe that namespaces are worth it. I also know that > I'm not alone in this.
I think adoption rates speak for themselves, I think there is far more demand for a fast & stable PHP then for syntatic sugar features which seem extremely useful, but in the end prove to carry too much baggage. Ilia Alshanetsky

Sean Coates

19 years ago
> PHP 6 is not yet out and probably won't be production quality for quite > some time. Which means that migration to it en mass is probably not > going to happen this decade :-).
<snippitysnip/> I'm not talking about forcing everyone to use namespaces tomorrow. I'm trying to plan for a future where there's a sensible way to avoid symbol collision. As for everyone developing on PHP $release-1 until 50% market saturation, I believe that to be the case in widely-distributed PHP apps (such as FUDForum), but you seem to be forgetting about the large number of PHP applications that are developed for internal use. I don't know of anyone currently using PHP 4 to develop new PHP apps unless they're for external distribution.
> I think there is far more > demand for a fast & stable PHP then for syntatic sugar features which > seem extremely useful, but in the end prove to carry too much baggage.
Nothing has been proven either way.. at least not publicly.. unless I just missed it. S

Ilia A.

19 years ago
On 10-Nov-06, at 1:19 PM, Sean Coates wrote:
>> PHP 6 is not yet out and probably won't be production quality for >> quite >> some time. Which means that migration to it en mass is probably not >> going to happen this decade :-). > <snippitysnip/> > > I'm not talking about forcing everyone to use namespaces tomorrow. I'm > trying to plan for a future where there's a sensible way to avoid > symbol > collision.
Since day one there was a sensible way to do, prefixing, but for whatever reason (and let's not get into that discussion) many people had not which is why we are having this problem today.
> As for everyone developing on PHP $release-1 until 50% market > saturation, I believe that to be the case in widely-distributed PHP > apps > (such as FUDForum), but you seem to be forgetting about the large > number > of PHP applications that are developed for internal use. I don't > know of > anyone currently using PHP 4 to develop new PHP apps unless they're > for > external distribution.
I was not referring to just the distributable applications, I know of many companies and people who develop internal software that's PHP4 only as they have no plans to move to PHP5. There is also a large number of ISPs providing exclusively PHP4 solutions, which effectively forces their client base to stick to PHP4. You also forget that a larger number of PHP developers started their development by looking at other people's code and using that as a base. Given that the base is predominantly PHP4 they tend to continue using PHP4. Ilia Alshanetsky

Hans Lellelid

19 years ago
>> I think there is far more >> demand for a fast & stable PHP then for syntatic sugar features which >> seem extremely useful, but in the end prove to carry too much baggage. >> > > Nothing has been proven either way.. at least not publicly.. unless I > just missed it. >
I haven't talked to a single developer a large-scale PHP tool, application, etc. that wouldn't switch their trunk to using namespaces tomorrow if they were adopted in the engine. We [in] PHP developers who are building "enterprise" open-source components and frameworks really will use this feature -- and I think we'd all argue that we really need this feature. I hope that namespaces would be more than syntactic sugar -- e.g. providing an import/using keyword that would declare namespace context -- but even if they were only "syntactic sugar" they would at minimum provide a naming standard for PHP packages to avoid collisions. Namespaces certainly got a lot of mention at Int'l PHP Conference (in form of request and, during the panel, applause from audience when mentioned); it was clear that this is a very anticipated PHP6 feature. None of us non-C developers are trying to say we think this should be easy, or trying to otherwise minimize the problems that have been presented in the past or the reasons why it hasn't been implemented so far, but let there be no confusion that this is a really, really important feature for us. Thanks, Hans

Jan Schneider

19 years ago
Zitat von Hans Lellelid <hans@velum.net>:
> >>> I think there is far more >>> demand for a fast & stable PHP then for syntatic sugar features which >>> seem extremely useful, but in the end prove to carry too much baggage. >>> >> >> Nothing has been proven either way.. at least not publicly.. unless I >> just missed it. >> > > I haven't talked to a single developer a large-scale PHP tool, > application, etc. that wouldn't switch their trunk to using namespaces > tomorrow if they were adopted in the engine. We [in] PHP developers who > are building "enterprise" open-source components and frameworks really > will use this feature -- and I think we'd all argue that we really need > this feature. I hope that namespaces would be more than syntactic sugar > -- e.g. providing an import/using keyword that would declare namespace > context -- but even if they were only "syntactic sugar" they would at > minimum provide a naming standard for PHP packages to avoid collisions. > > Namespaces certainly got a lot of mention at Int'l PHP Conference (in > form of request and, during the panel, applause from audience when > mentioned); it was clear that this is a very anticipated PHP6 feature. > None of us non-C developers are trying to say we think this should be > easy, or trying to otherwise minimize the problems that have been > presented in the past or the reasons why it hasn't been implemented so > far, but let there be no confusion that this is a really, really > important feature for us.
I couldn't agree more. There really wasn't an appealing reason to switch to PHP5 too quickly for me, and force the users of our code to do the same. There are a few reasons to switch to 5.2 probably, but that's a different story. But if there wasn't already Unicode support in PHP 6, having namespaces was definitely a good reason to force our user to that version. Jan.
-- Do you need professional PHP or Horde consulting? http://horde.org/consulting/

Rasmus Lerdorf

19 years ago
I am not sure why this thread was revived. We decided long ago that we would have namespaces in PHP 6 barring any nasty technical problems and assuming a good way to implement it could be found. And I'll second Tony here and mention that we really could use more eyeballs on the bug database. I am sure everyone reading internals has at least one part of PHP they know really well and it would be extremely helpful if you could all pick a topic and watch for bugs related to that topic. It's not hard to see just the bugs you care about. For all the open Postgresql Related bugs, for example: http://bugs.php.net/search.php?limit=50&order_by=id&direction=DESC&cmd=display&bug_type%5B%5D=PostgreSQL+related&status=Open Or if you prefer to have them show up in your RSS reader, just put rss in front of the search.php script there: http://bugs.php.net/rss/search.php?limit=50&order_by=id&direction=DESC&cmd=display&bug_type%5B%5D=PostgreSQL+related&status=Open Go to http://bugs.php.net/search.php for a list of all the available categories or even better, just watch for all bugs coming in and attack the ones you think you might have a clue on. http://bugs.php.net/rss/search.php?direction=DESC&status=Open&cmd=display You don't necessarily have to be able to fix them in the C code, just helping to get rid of bogus reports or translating the really bad reports into a simple reproducable test case is often the part that takes the most time. Once we have a 3-5 line reproducing script, the fix is usually easy. -Rasmus

David Zülke

19 years ago
Am 11.11.2006 um 14:37 schrieb Rasmus Lerdorf:
> I am not sure why this thread was revived. We decided long ago > that we > would have namespaces in PHP 6 barring any nasty technical problems > and > assuming a good way to implement it could be found.
I'm not sure if that was made clear. The meeting notes much rather say "mmmh okay we'll think about it, and if we like the idea, Marcus is gonna implement it". I'm glad that was clarified now, thanks :) David

Richard Lynch

19 years ago
On Sat, November 11, 2006 7:37 am, Rasmus Lerdorf wrote:
> helping to get rid of bogus reports or translating the really bad > reports into a simple reproducable test case is often the part that
This is a plea for not being quite so bogus-trigger-happy as we have in the past. Many correct, if incomplete, bug reports get quickly labeled "bogus" with no real research, and that only makes it even harder for anybody to do anything useful... I know it's [hard] work to wade through those things, to some degree, but you make your life more miserable with incorrect assessment. :-) Please do not take this request amiss! It is an attempt, however small, to make your life better, not to complain about your efforts!
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

Rasmus Lerdorf

19 years ago
Richard Lynch wrote:
> On Sat, November 11, 2006 7:37 am, Rasmus Lerdorf wrote: >> helping to get rid of bogus reports or translating the really bad >> reports into a simple reproducable test case is often the part that > > This is a plea for not being quite so bogus-trigger-happy as we have > in the past. > > Many correct, if incomplete, bug reports get quickly labeled "bogus" > with no real research, and that only makes it even harder for anybody > to do anything useful... > > I know it's [hard] work to wade through those things, to some degree, > but you make your life more miserable with incorrect assessment. :-) > > Please do not take this request amiss! It is an attempt, however > small, to make your life better, not to complain about your efforts!
I think lagging 6-12 months behind on bug reports would be much worse. If the bug report is incomplete and isn't likely to lead to a resolution I think it is better to let the reporter know sooner rather than later. The fact that we only have 2 or 3 people regularly looking at these and the flow of them is ever increasing doesn't leave us with much choice here. If more people helped out we could spend more time on each one, but until that happens, the quick-bogus is going to continue. -Rasmus

David Zülke

19 years ago
Am 10.11.2006 um 19:47 schrieb Hans Lellelid:
> >>> I think there is far more >>> demand for a fast & stable PHP then for syntatic sugar features >>> which >>> seem extremely useful, but in the end prove to carry too much >>> baggage. >>> >> >> Nothing has been proven either way.. at least not publicly.. unless I >> just missed it. >> > > I haven't talked to a single developer a large-scale PHP tool, > application, etc. that wouldn't switch their trunk to using namespaces > tomorrow if they were adopted in the engine. We [in] PHP > developers who > are building "enterprise" open-source components and frameworks really > will use this feature -- and I think we'd all argue that we really > need > this feature. I hope that namespaces would be more than syntactic > sugar > -- e.g. providing an import/using keyword that would declare namespace > context -- but even if they were only "syntactic sugar" they would at > minimum provide a naming standard for PHP packages to avoid > collisions. > > Namespaces certainly got a lot of mention at Int'l PHP Conference (in > form of request and, during the panel, applause from audience when > mentioned); it was clear that this is a very anticipated PHP6 feature. > None of us non-C developers are trying to say we think this should be > easy, or trying to otherwise minimize the problems that have been > presented in the past or the reasons why it hasn't been implemented so > far, but let there be no confusion that this is a really, really > important feature for us.
Very wall said, Hans, and I totally agree. It's much needed, and I believe any FOSS project that is OO based would applaud the introduction of namespaces. David

Derick Rethans

19 years ago
On Fri, 10 Nov 2006, Hans Lellelid wrote:
> > >> I think there is far more > >> demand for a fast & stable PHP then for syntatic sugar features which > >> seem extremely useful, but in the end prove to carry too much baggage. > >> > > > > Nothing has been proven either way.. at least not publicly.. unless I > > just missed it. > > I haven't talked to a single developer a large-scale PHP tool, > application, etc. that wouldn't switch their trunk to using namespaces > tomorrow if they were adopted in the engine.
You did now then. YOu can't simply switch to using namespaces as you'd have two branches to maintain that suddendly. Although namespaces would have helped if it was there from the beginning, we have no problems with using prefixes at all. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Richard Lynch

19 years ago
On Fri, November 10, 2006 12:19 pm, Sean Coates wrote:
> of PHP applications that are developed for internal use. I don't know > of > anyone currently using PHP 4 to develop new PHP apps unless they're > for > external distribution.
Are you living in a bubble? :-) :-) :-) There's a zillion ISPs that are not upgrading to 5, and all their customers are developing new apps in 4. They may not be big famous super-slick widely-distributed apps, but they are the "long tail" of your userbase.
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

Daniel T. Gorski

19 years ago
On 10 Nov 13:05, Ilia Alshanetsky wrote:
> On 10-Nov-06, at 12:41 PM, Sean Coates wrote:
>> [...]
>> I also don't deny that there will be a minor performance hit. There are a >> ton of other things in PHP that reduce performance.. the idea is to find >> a balance of which ones are worth it (as we did with OOP and Unicode), >> and I believe that namespaces are worth it. I also know that I'm not >> alone in this.
> I think adoption rates speak for themselves, I think there is far > more demand for a fast & stable PHP then for syntatic sugar features > which seem extremely useful, but in the end prove to carry too much > baggage.
Escpecially due to the new OO features of PHP 5, namespaces are urgently required for writers of independent libraries which should not clash. For me, I even would accept 10% performance loss to have namespaces implemented: I'd use a faster machine instead, which is cheaper compared to the adjustment of clashing class names from different libraries or frameworks. Unfortunately namespaces are not only syntactic sugar, but dire necessity for PHP if it wants to be taken as a serious langauage and defend it's position against other arising 'web scripting' alternatives. But I suppose, you know this. Just my two cents, regards dtg

Brian Moon

19 years ago
> Unfortunately namespaces are not only syntactic sugar, but dire necessity > for PHP if it wants to be taken as a serious langauage and defend it's > position against other arising 'web scripting' alternatives.
It seems the list of things that PHP needs to be "taken as a serious langauage" is never ending. Before PHP 5, all that was needed was good OOP support. Now this. I am for namespaces, but that line is getting old and I, a professional, serious PHP developer and tired of hearing it.
-- Brian Moon ------------- http://dealnews.com/ It's good to be cheap =)

Hans Lellelid

19 years ago
Brian Moon wrote:
>> Unfortunately namespaces are not only syntactic sugar, but dire >> necessity >> for PHP if it wants to be taken as a serious langauage and defend it's >> position against other arising 'web scripting' alternatives. > > It seems the list of things that PHP needs to be "taken as a serious > langauage" is never ending. Before PHP 5, all that was needed was > good OOP support. Now this. I am for namespaces, but that line is > getting old and I, a professional, serious PHP developer and tired of > hearing it.
I think that one reason why this list is never ending is that these languages are constantly moving targets -- I would hope that what people expected of a web development language would evolve over the course of several years. Daniel's project (coWiki) was one of the first (if not the absolute first) to show us what was possible with PHP5 and Exceptions; that was some pretty serious PHP. I think what Daniel means is that to remain competitive, PHP needs to include the features that developers have come to expect of a language -- and developers are constantly changing, maturing, working on bigger & bigger projects, integrating more & more components. I think PHP has been very responsive to the needs of the constantly maturing user community, drastically changing its language to support new & better OOP, Exceptions, etc. Indeed, this responsiveness to an increasingly OO userbase is why many of us who started with PHP are still using it today. Namespaces may be the most fervent request lately, but it would be very sad for PHP if it were to be the last. Hans

Marcus Börger

19 years ago
Hello Hans, Friday, November 10, 2006, 8:30:55 PM, you wrote:
> Brian Moon wrote: >>> Unfortunately namespaces are not only syntactic sugar, but dire >>> necessity >>> for PHP if it wants to be taken as a serious langauage and defend it's >>> position against other arising 'web scripting' alternatives. >> >> It seems the list of things that PHP needs to be "taken as a serious >> langauage" is never ending. Before PHP 5, all that was needed was >> good OOP support. Now this. I am for namespaces, but that line is >> getting old and I, a professional, serious PHP developer and tired of >> hearing it.
> I think that one reason why this list is never ending is that these > languages are constantly moving targets -- I would hope that what people > expected of a web development language would evolve over the course of > several years. Daniel's project (coWiki) was one of the first (if not > the absolute first) to show us what was possible with PHP5 and > Exceptions; that was some pretty serious PHP. I think what Daniel means > is that to remain competitive, PHP needs to include the features that > developers have come to expect of a language -- and developers are > constantly changing, maturing, working on bigger & bigger projects, > integrating more & more components. I think PHP has been very > responsive to the needs of the constantly maturing user community, > drastically changing its language to support new & better OOP, > Exceptions, etc. Indeed, this responsiveness to an increasingly OO > userbase is why many of us who started with PHP are still using it > today. Namespaces may be the most fervent request lately, but it would > be very sad for PHP if it were to be the last.
Very nice writing, I completley agree. The world is changing, so are computer languages, so will we... :-) Best regards, Marcus

Robert Cummings

19 years ago
On Sat, 2006-11-11 at 00:31 +0100, Marcus Boerger wrote:
> Hello Hans, > > Friday, November 10, 2006, 8:30:55 PM, you wrote: > > > Brian Moon wrote: > >>> Unfortunately namespaces are not only syntactic sugar, but dire > >>> necessity > >>> for PHP if it wants to be taken as a serious langauage and defend it's > >>> position against other arising 'web scripting' alternatives. > >> > >> It seems the list of things that PHP needs to be "taken as a serious > >> langauage" is never ending. Before PHP 5, all that was needed was > >> good OOP support. Now this. I am for namespaces, but that line is > >> getting old and I, a professional, serious PHP developer and tired of > >> hearing it. > > > I think that one reason why this list is never ending is that these > > languages are constantly moving targets -- I would hope that what people > > expected of a web development language would evolve over the course of > > several years. Daniel's project (coWiki) was one of the first (if not > > the absolute first) to show us what was possible with PHP5 and > > Exceptions; that was some pretty serious PHP. I think what Daniel means > > is that to remain competitive, PHP needs to include the features that > > developers have come to expect of a language
Many developers came to PHP in spite of what other developers had come to expect in other languages. Cheers, Rob.
-- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------'

Richard Lynch

19 years ago
On Fri, November 10, 2006 1:07 pm, Brian Moon wrote:
>> Unfortunately namespaces are not only syntactic sugar, but dire >> necessity >> for PHP if it wants to be taken as a serious langauage and defend >> it's >> position against other arising 'web scripting' alternatives. > > It seems the list of things that PHP needs to be "taken as a serious > langauage" is never ending. Before PHP 5, all that was needed was > good > OOP support. Now this. I am for namespaces, but that line is getting > old and I, a professional, serious PHP developer and tired of hearing > it.
I was tired of it before the OOP stuff... :-) Honestly, I think PHP's record of usage speaks far more volumes about its quality and utility than any ribbing from "other" language users. I'm reminded of how often we used to rib MS users of how their OS wasn't a "real" OS because it couldn't do X, so they finally fixed it to do X a couple years ago... [Something or other about TCP/IP/SMTP/raw/root access, if you care to refresh my memory...] The end result, though, after they "fixed" it, was that we had a zillion more security holes and viruses because now normal scripts could punch through with this new feature. Anyway, my point is that I also believe namespaces would be "good" for those who need to distribute libraries and whatnot, possibly even more important than OOP was in the first place -- As much of the OOP code is little more than a namespace substitute in the first place.
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

Patrick Mueller

19 years ago
Daniel T. Gorski wrote:
> Escpecially due to the new OO features of PHP 5, namespaces are urgently > required for writers of independent libraries which should not clash.
I would claim exactly the opposite. That's because you already get scoping on names, for free, when you use objects. The method and field names. Of course, for static methods and fields you'll need to reference the class name again ... so don't do that :-) There would typically be a one time 'hit' in your code for a long, prefixed named used as a constructor, or possibly a static method called on a factory. After that, if you're dealing with object instances, then instead of function names (which would need to also use a longish prefix, because they are scoped globally), you can use plain old short method names.
-- Patrick_Mueller@us.ibm.com IBM PHP Community Architect, IBM Research Triangle Park

Tony Bibbs

19 years ago
While I could munge the class names in one or more packages as you suggest then I'm in maintainability hell because when I need to update one of the other packages (for security, features or bugfixes) you have to do the name munging again. C'mon, that ain't right. Next excuse? --Tony Patrick Mueller wrote:

Ilia A.

19 years ago
On 10-Nov-06, at 4:57 PM, Tony Bibbs wrote:
> While I could munge the class names in one or more packages as you > suggest then I'm in maintainability hell because when I need to > update one of the other packages (for security, features or > bugfixes) you have to do the name munging again.
What? I suppose if you always want to name your latest class foobar, then yes, but then you have other problems... If you properly pick a classname you almost never need to rename it let alone the methods contained with the class. Plus namespaces are going to introduce their own sets of problems where extension X adds namespace X, which some lib already decided to use and we are back to where we are at today. Ilia Alshanetsky

Tony Bibbs

19 years ago
Ilia Alshanetsky wrote:
> If you properly pick a > classname you almost never need to rename it let alone the methods > contained with the class. Plus namespaces are going to introduce their > own sets of problems where extension X adds namespace X, which some lib > already decided to use and we are back to where we are at today.
In third party packages that choice isn't up to me. And as for your extensions using the same namespace...I see that argument as a bit better reasoning but would it not be easier to fix the namespace declarations than having to fix ALL the uses of some class? As a casual observer of this list and proponent of PHP I'd like to see the namespace issue either get done or die. Many watching the namespace issue with interest are growing tired of excuses as to why it shouldn't be done. Do it. Don't do it. Just choose and be on with it. PHP developers will deal with the outcome fine. That isn't criticism directed at anyone but dragging this out is only stirring emotions. I think putting this behind us all - one way or another - is good for everybody. --Tony

David Zülke

19 years ago
> What? I suppose if you always want to name your latest class > foobar, then yes, but then you have other problems... If you > properly pick a classname you almost never need to rename it let > alone the methods contained with the class. Plus namespaces are > going to introduce their own sets of problems where extension X > adds namespace X, which some lib already decided to use and we are > back to where we are at today.
import('org.phpdb.propel.runtime'); or whatever. How could that possibly collide. Come on, "people might use namespaces in a wrong way" really is not an argument against them. David

Patrick Mueller

19 years ago
Tony Bibbs wrote:
> While I could munge the class names in one or more packages as you > suggest then I'm in maintainability hell because when I need to update > one of the other packages (for security, features or bugfixes) you have > to do the name munging again. > > C'mon, that ain't right. Next excuse?
Sorry. I'm assuming here that you are giving your class names 'prefixed' names. Like Zend Framework is doing. For what it's worth, >10 years ago we were in this same position with Smalltalk; and specifically, IBM Smalltalk. Tradtional Smalltalk does not have namespaces. And neither did ours - we were traditional :-) So, we used product prefixes. We had a relatively hugemongous class library, a fairly large, distributed team, and just a handful of prefixes. It was 'ugly', to some extent, but it did work. Later, we added namespaces. I never used 'em. Not sure if anyone did. We added them because the masses roared for them. I don't think they used 'em either. Because they were kinda horky. (Be careful what you ask for, because you might just get it) Point is, if you're doing OO in the usual fashion, the only time you need to reference globally scoped names is when you reference the class itself, which is when you invoke constructors, or call static methods. Instance method invocation was used waaaaaay more often than those two.
-- Patrick_Mueller@us.ibm.com IBM PHP Community Architect, IBM Research Triangle Park

Lukas Smith

19 years ago
Patrick Mueller wrote:
> There would typically be a one time 'hit' in your code for a long, > prefixed named used as a constructor, or possibly a static method called > on a factory. After that, if you're dealing with object instances, then > instead of function names (which would need to also use a longish > prefix, because they are scoped globally), you can use plain old short > method names.
Remember the point Sebastian made earlier. Its also a hassle during development of the library code itself, where you have to deal with endlessly long class names. regards, Lukas

Ilia A.

19 years ago
On 10-Nov-06, at 5:01 PM, Lukas Kahwe Smith wrote:
> Remember the point Sebastian made earlier. Its also a hassle during > development of the library code itself, where you have to deal with > endlessly long class names.
You still have the same long names, you've just split them into two namespaces + classname rather then just one class name. Ilia Alshanetsky

Richard Lynch

19 years ago
On Fri, November 10, 2006 4:07 pm, Ilia Alshanetsky wrote:
> On 10-Nov-06, at 5:01 PM, Lukas Kahwe Smith wrote: >> Remember the point Sebastian made earlier. Its also a hassle during >> development of the library code itself, where you have to deal with >> endlessly long class names. > > You still have the same long names, you've just split them into two > namespaces + classname rather then just one class name.
This all also rather depends upon the eventual implementation. I'm sure you're aware that in some languages it is possible to 'import' another namespace and re-name it to NOT conflict with existing namespaces. This also allows one to short the name of the namespace if it is ridiculously long: import('stupidly_long_brand_aware_name_space_foo.php', 'foo'); That feature may already be "off the table" for PHP in this discussion, but it may explain this dichotomy of what different posters are thinking namespaces will "fix" or "not fix"...
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

Sebastian Bergmann

19 years ago
Ilia Alshanetsky wrote:
> If anything it'll make code complex and intertwined, introduce serious > scope issue most people have not had to consider up until now and so > on. It will without a doubt increase language complexity as well, which > generally translates to a loss in performance.
Am I right to assume that both scoping and performance issues only come up if we were to implement an import() mechanism? If so, do we really need import? If not, then namespace foo { class bar { } } would be "mangled" at compile-time into foo\bar and should not impose any performance penalty or scoping issues. Not having an import() mechanism, however, would mean that the user of a namespaced package has to use "fully qualified" class names (like foo\bar, for instance) while the developer of the namespaced package can (and should) use the "relative" class name. We would still get two benefits out of this: - The developer of a package does not need to worry that his class (or constant, function) names clash with his package's users. - The developer of a package can shorten the class names inside his namespaced package significantly. PHPUnit_Framework_TestCase {} would become namespace PHPUnit { namespace Framework { class TestCase {} } } Classes inside PHPUnit\Framework could refer to the class as just TestCase, classes inside PHPUnit as Framework\TestCase, and classes outside PHPUnit as PHPUnit\Framework\TestCase.
-- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Ilia A.

19 years ago
On 10-Nov-06, at 12:54 PM, Sebastian Bergmann wrote:
> Ilia Alshanetsky wrote: >> If anything it'll make code complex and intertwined, introduce >> serious >> scope issue most people have not had to consider up until now and so >> on. It will without a doubt increase language complexity as well, >> which >> generally translates to a loss in performance. > > Am I right to assume that both scoping and performance issues only > come > up if we were to implement an import() mechanism? If so, do we really > need import? > > If not, then > > namespace foo > { > class bar > { > } > } > > would be "mangled" at compile-time into foo\bar and should not impose > any performance penalty or scoping issues.
As your key size increases the slower the key hash generation process becomes, if you look at the PHP's hash key generation code you'll see that it works best for 8 or less chars, anything longer and the performance starts to drop. Add to this case-sensitivity issues and you have an additional draw on your speed. Obviously, by doing things at compile time you reduce overhead, so it is a good idea, but it will not eliminate the performance penalties, it'll probable halve them however. Ilia Alshanetsky

Sebastian Bergmann

19 years ago
Ilia Alshanetsky wrote:
> As your key size increases the slower the key hash generation process > becomes, if you look at the PHP's hash key generation code you'll see > that it works best for 8 or less chars, anything longer and the > performance starts to drop.
It's been a long time since I studied hashes: are there no hashing algorithms that perform better with more than 8 characters?
-- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Marcus Börger

19 years ago
Hello Sebastian, the best ones unfortunatley are GPL and thus not acceptable. I once played with case insensitive hashes. They worked very much faster - but they had more conflicts. If we were about intel processors my experience is that string functions can be optimized at assembler level very much. For instance i once ago increased string up/downcase by 32 times using a table based xlat approach that was reading the string in chunks of 4 byte. Maybe itcould be interesting to see whether we could come up with a version that takes 4 byte or 8 byte chunks depending on the cpu. And eventually we have hash codes in 64 bit machines be 8 bytes long as well. best regards marcus Friday, November 10, 2006, 7:20:59 PM, you wrote:
> Ilia Alshanetsky wrote: >> As your key size increases the slower the key hash generation process >> becomes, if you look at the PHP's hash key generation code you'll see >> that it works best for 8 or less chars, anything longer and the >> performance starts to drop.
> It's been a long time since I studied hashes: are there no hashing > algorithms that perform better with more than 8 characters?
> -- > Sebastian Bergmann http://sebastian-bergmann.de/ > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Best regards, Marcus

Andi Gutmans

19 years ago
Too long of an email to read :) but just wanted to give a heads-up that we haven't forgotten about this (it's on the PHP 6 list). We'll try and come with a proposal in the coming weeks with a way to do it.

DvDmanDT

19 years ago
Hello Internals. I'm not sure how many of you know about Phalanger [1][2]. For those who don't, it's a fairly complete PHP language compiler, compiling PHP5 sources into MSIL bytecodes, which can then be executed on the .NET platform or Mono. Since the .NET framework makes heavy use of namespaces, Phalanger had to support it (from version 2.0). For those who already knew about Phalanger and consider it obsolete after looking at version 1.x, I'd say take a look at version 2.0b3, now it's accutually intresting. For all the developers worldwide, I'd say it'd be nice if all implentations used the same syntax. The Phalanger team went with the ::: syntax, possibly 'cause it seemed to get most votes last time the issue was up. I'm not saying it should be a deciding factor, but taking it into consideration wouldn't hurt, and should you decide against :::, I'm sure it would be greatly appreciated if you at least did so before it gets widespread use. Disclaimer: I'm not part of the Phalanger team, and I have never had anything to do with them. The above comments and thoughts are mine as a PHP developer, with an additional interest in the possibilites of the .NET platform/framework. (As a sidenote, Phalanger isn't the only other implentation currently avaible, perhaps it's time to write down a standards document?) [1] http://www.codeplex.com/Phalanger [2] http://www.php-compiler.net/
-- "Sean Coates" <sean@caedmon.net> skrev i meddelandet news:4554AE0D.4080600@caedmon.net...

Jessie Hernandez

19 years ago
Hello, I haven't had time to work on my patch, but thinking about this some more, I'm convinced namespaces should only contain classes. The only problem that was present when permitting functions/constants to be inside namespaces was the ambiguity in ternary expressions. By just supporting classes inside namespaces, this issue would go away. Besides, I'll dare say that most, if not all, the developers who want namespaces will only group classes with it anyways, Also, by only supporting classes, we can use ":" instead of the long ":::" separator and everyone would be happy. Last I checked, the only things that were pending on my patch were some scoping issues which I had to fix. These are listed below. Once these are done, the patch can be formally proposed. If anyone wants to take a look at the patch so far and/or work on the remaining issues below, let me know and I'll either post the patch or email it. Pending: 1) The extends clause should resolve imported class names. import class ns:DateBase; namespace ns{ class Date extends DateBase{} } 2) To access a global symbol, use global:<class_name> syntax. 3) Type hints should also consider imported classes. 4) When an import is done (with alias or not), and a global class with that same name exists, what is the desired behavior? Error? Global takes precedence? Regards, Jessie Hernandez Sean Coates wrote:

Marcus Börger

19 years ago
Hello Jessie, sorry to say this but look at the following, keeping in mind that the whitespace is optional. $x = $foo ? class:const : $var // 1, 0 $x = $foo ? class:const : const; // 1, 0 $x = $foo ? class:const : class:const; // 1, 1 $x = $foo ? class:const : namespace:class:const; // 1, 2 $x = $foo ? namespace:class:const : $var; // 2, 0 $x = $foo ? namespace:class:const : const; // 2, 0 $x = $foo ? namespace:class:const : class:const; // 2, 1 $x = $foo ? namespace:class:const : namespace:class:const; // 2, 2 Feel free to continue that list, it has conflicts whatever you do. Saturday, November 11, 2006, 5:13:22 AM, you wrote:
> Hello,
> I haven't had time to work on my patch, but thinking about this some > more, I'm convinced namespaces should only contain classes. The only > problem that was present when permitting functions/constants to be > inside namespaces was the ambiguity in ternary expressions. By just > supporting classes inside namespaces, this issue would go away. Besides, > I'll dare say that most, if not all, the developers who want namespaces > will only group classes with it anyways,
> Also, by only supporting classes, we can use ":" instead of the long > ":::" separator and everyone would be happy.
> Last I checked, the only things that were pending on my patch were some > scoping issues which I had to fix. These are listed below. Once these > are done, the patch can be formally proposed. If anyone wants to take a > look at the patch so far and/or work on the remaining issues below, let > me know and I'll either post the patch or email it.
> Pending:
> 1) The extends clause should resolve imported class names.
> import class ns:DateBase;
> namespace ns{ class Date extends DateBase{} }
> 2) To access a global symbol, use global:<class_name> syntax.
I would prefer ':::'<class_name> or '\'<class_name> but that doesn't really matter as we have 'global' as a keyword already.
> 3) Type hints should also consider imported classes.
> 4) When an import is done (with alias or not), and a global class with > that same name exists, what is the desired behavior? Error? Global takes > precedence?
Maybe this new discussion gave one hint. Aliases could be solved with a flag. Just copy the classwith a new name into the classlist again and flagit as copy. Maybe the original class gets a list of the copies of the copies a pointer to the original but that would be an implementation detail. As soon as that is done importdoes nothingelse then copying classes on a single class table. That said namespaces would, if after all, simply contain other copies to the original classes. In the extremecase we can start with namespaces only being a 'stupid' list. Reflection could then travers all classes to see in which namespaces it was registered. This btw would also fix 3) as the namespace seperator would be a normal sign in class lookup, it would simply be disallowed in definitions of class/interface/namespaces. Best regards, Marcus

Jessie Hernandez

19 years ago
Hi Marcus, As I said, I wanted to only enable classes inside namespaces, and NOT allow functions or constants. class::const would stay the same, so there are no conflicts. Marcus Boerger wrote:

Stefan Walk

19 years ago
Hi! If the namespace-approach only covers classes it is implemented half-heartedly, IMO. I see a lot of "classes" that are just really collections of static functions, that's what namespaces should cover, too. And disallowing constants only so that : works is a bad tradeoff... Regards, Stefan

Jessie Hernandez

19 years ago
What does everyone else think? Are functions/constants inside namespaces really that critical? Anyways, I just thought of a possible solution to the namespace separator issue, and if it's doable, then the double colon (::) can even be used and no conflicts would occur. It seems the biggest problem with handling namespaces is determining if a symbol is a class or namespace at compile-time. I am no expert in flex/bison, but I was thinking that a state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on whether the symbol is known to be a class or namespace. The user will add either a "using" or "import" statement before the use of the symbol, and this will allow the parser to know what that symbol is in the compilation phase. As an example: // BEGIN CODE using namespace PEAR::File; $items = File::Find::glob( '!.*\.php$!', $dir, 'perl' ); // END CODE The first statement will add an entry into a hashtable (used during compilation) indicating that "PEAR", "PEAR::File", and "File" are namespaces ("File" will be imported in the current file only). When "File::Find::glob" is parsed, the compiler already knows that "File" is a namespace, so "Find" must be a class inside that namespace, and "glob" must be a static method. With this, functions and constants can easily be added inside namespaces, as the "using" or "import" statement will indicate to the parser which portion of the qualified name is a namespace. Is this feasible in flex/bison? Let me know if anything needs clarification. Regards, Jessie Hernandez Stefan Walk wrote:

Marcus Börger

19 years ago
Hello Jessie, Tuesday, November 14, 2006, 5:00:42 AM, you wrote:
> What does everyone else think? Are functions/constants inside namespaces > really that critical?
> Anyways, I just thought of a possible solution to the namespace > separator issue, and if it's doable, then the double colon (::) can even > be used and no conflicts would occur. It seems the biggest problem with > handling namespaces is determining if a symbol is a class or namespace > at compile-time. I am no expert in flex/bison, but I was thinking that a > state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will > return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on > whether the symbol is known to be a class or namespace. The user will > add either a "using" or "import" statement before the use of the symbol, > and this will allow the parser to know what that symbol is in the > compilation phase. As an example:
> // BEGIN CODE > using namespace PEAR::File; > $items = File::Find::glob( '!.*\.php$!', $dir, 'perl' ); > // END CODE
> The first statement will add an entry into a hashtable (used during > compilation) indicating that "PEAR", "PEAR::File", and "File" are > namespaces ("File" will be imported in the current file only). When > "File::Find::glob" is parsed, the compiler already knows that "File" is > a namespace, so "Find" must be a class inside that namespace, and "glob" > must be a static method. With this, functions and constants can easily > be added inside namespaces, as the "using" or "import" statement will > indicate to the parser which portion of the qualified name is a namespace.
> Is this feasible in flex/bison? Let me know if anything needs clarification.
Short: no Long: Please stop confusion here. We will get namespace innwith either ":::" or "\" depending on who is going to implement it and what otherissues that one will encounter. Later we may decide based on that implementation whether it might be possible to use a different seperator. Btw, ifI wereto implement namespacesupport today i would go with "\" as that is easier to translate to a directory/file name in an __autoload function. While yesturday people nearly convinced me (during the last conferences) that ":::" is closer to the class/member seperator "::". best regards marcus

Richard Quadling

19 years ago
The only issue with using \ is the fact that this is the escape character. If you are using PHP to create classes (collapsing complex classes into simpler ones, implementing a fake AOP), you have to remember to escape the escape. It just seems odd to re-use a symbol like this. A new symbol is better. IIHMY, I would use # and remove # from comments. # looks like a grid which can be thought of as a compartmentalisation process; i.e. grouping things together in their own little space - a perfect concept to explain namespaces. We already have singleline and block comments with // and /* ... */. Not really sure of the need of #. Of course, this would be an evern bigger BC. Even my own code uses #. The triple colon (:::) is OK, but what happens during a mistype. Is there a possibility that :: and ::: COULD be used interchangably (an extreme example), producing working code? On 14/11/06, Marcus Boerger <helly@php.net> wrote:
> Hello Jessie, > > Tuesday, November 14, 2006, 5:00:42 AM, you wrote: > > > What does everyone else think? Are functions/constants inside namespaces > > really that critical? > > > Anyways, I just thought of a possible solution to the namespace > > separator issue, and if it's doable, then the double colon (::) can even > > be used and no conflicts would occur. It seems the biggest problem with > > handling namespaces is determining if a symbol is a class or namespace > > at compile-time. I am no expert in flex/bison, but I was thinking that a > > state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will > > return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on > > whether the symbol is known to be a class or namespace. The user will > > add either a "using" or "import" statement before the use of the symbol, > > and this will allow the parser to know what that symbol is in the > > compilation phase. As an example: > > > > // BEGIN CODE > > using namespace PEAR::File; > > $items = File::Find::glob( '!.*\.php$!', $dir, 'perl' ); > > // END CODE > > > > The first statement will add an entry into a hashtable (used during > > compilation) indicating that "PEAR", "PEAR::File", and "File" are > > namespaces ("File" will be imported in the current file only). When > > "File::Find::glob" is parsed, the compiler already knows that "File" is > > a namespace, so "Find" must be a class inside that namespace, and "glob" > > must be a static method. With this, functions and constants can easily > > be added inside namespaces, as the "using" or "import" statement will > > indicate to the parser which portion of the qualified name is a namespace. > > > Is this feasible in flex/bison? Let me know if anything needs clarification. > > Short: no > > Long: Please stop confusion here. We will get namespace innwith either ":::" > or "\" depending on who is going to implement it and what otherissues that > one will encounter. Later we may decide based on that implementation whether > it might be possible to use a different seperator. Btw, ifI wereto implement > namespacesupport today i would go with "\" as that is easier to translate to > a directory/file name in an __autoload function. While yesturday people > nearly convinced me (during the last conferences) that ":::" is closer to > the class/member seperator "::". > > best regards > marcus > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Marcus Börger

19 years ago
Hello Richard, The "#" is needed for CLI mode - thus we won't remove it. In fact we will not do anything that would cause BC problems. Also there is no escaping issue with "\". If there is than it is outside of PHP. In other words: - "\" is the only single character reachable from 'western' keyboards - $foo = "{mynamespace\myclass::myconst}"; // will be possible without escaping Please people read the archives before posting here, we have discussed all this long enough. Tuesday, November 14, 2006, 9:36:10 AM, you wrote:
> The only issue with using \ is the fact that this is the escape > character. If you are using PHP to create classes (collapsing complex > classes into simpler ones, implementing a fake AOP), you have to > remember to escape the escape. It just seems odd to re-use a symbol > like this. A new symbol is better. IIHMY, I would use # and remove # > from comments. # looks like a grid which can be thought of as a > compartmentalisation process; i.e. grouping things together in their > own little space - a perfect concept to explain namespaces. We already > have singleline and block comments with // and /* ... */. Not really > sure of the need of #. Of course, this would be an evern bigger BC. > Even my own code uses #.
> The triple colon (:::) is OK, but what happens during a mistype. Is > there a possibility that :: and ::: COULD be used interchangably (an > extreme example), producing working code?
> On 14/11/06, Marcus Boerger <helly@php.net> wrote: >> Hello Jessie, >> >> Tuesday, November 14, 2006, 5:00:42 AM, you wrote: >> >> > What does everyone else think? Are functions/constants inside namespaces >> > really that critical? >> >> > Anyways, I just thought of a possible solution to the namespace >> > separator issue, and if it's doable, then the double colon (::) can even >> > be used and no conflicts would occur. It seems the biggest problem with >> > handling namespaces is determining if a symbol is a class or namespace >> > at compile-time. I am no expert in flex/bison, but I was thinking that a >> > state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will >> > return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on >> > whether the symbol is known to be a class or namespace. The user will >> > add either a "using" or "import" statement before the use of the symbol, >> > and this will allow the parser to know what that symbol is in the >> > compilation phase. As an example: >> >> >> > // BEGIN CODE >> > using namespace PEAR::File; >> > $items = File::Find::glob( '!.*\.php$!', $dir, 'perl' ); >> > // END CODE >> >> >> > The first statement will add an entry into a hashtable (used during >> > compilation) indicating that "PEAR", "PEAR::File", and "File" are >> > namespaces ("File" will be imported in the current file only). When >> > "File::Find::glob" is parsed, the compiler already knows that "File" is >> > a namespace, so "Find" must be a class inside that namespace, and "glob" >> > must be a static method. With this, functions and constants can easily >> > be added inside namespaces, as the "using" or "import" statement will >> > indicate to the parser which portion of the qualified name is a namespace. >> >> > Is this feasible in flex/bison? Let me know if anything needs clarification. >> >> Short: no >> >> Long: Please stop confusion here. We will get namespace innwith either ":::" >> or "\" depending on who is going to implement it and what otherissues that >> one will encounter. Later we may decide based on that implementation whether >> it might be possible to use a different seperator. Btw, ifI wereto implement >> namespacesupport today i would go with "\" as that is easier to translate to >> a directory/file name in an __autoload function. While yesturday people >> nearly convinced me (during the last conferences) that ":::" is closer to >> the class/member seperator "::". >> >> best regards >> marcus >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >>
Best regards, Marcus

Lukas Smith

19 years ago
Marcus Boerger wrote:
> Hello Richard, > > The "#" is needed for CLI mode - thus we won't remove it. In fact we > will not do anything that would cause BC problems. Also there is no > escaping issue with "\". If there is than it is outside of PHP. In > other words: > - "\" is the only single character reachable from 'western' keyboards > - $foo = "{mynamespace\myclass::myconst}"; // will be possible without > escaping > > Please people read the archives before posting here, we have discussed > all this long enough.
Jessie, Sean, would you guys be interested in writing up an overview of the namespace decisions on my todo wiki? regards, Lukas

Richard Quadling

19 years ago
Would $foo = "{mynamespace\tables_class::myconst}"; \t in "" is a tab. \m in "" is nothing but \m Thats the sort of thing I'm worried about. On 14/11/06, Marcus Boerger <helly@php.net> wrote:
> Hello Richard, > > The "#" is needed for CLI mode - thus we won't remove it. In fact we > will not do anything that would cause BC problems. Also there is no > escaping issue with "\". If there is than it is outside of PHP. In > other words: > - "\" is the only single character reachable from 'western' keyboards > - $foo = "{mynamespace\myclass::myconst}"; // will be possible without > escaping > > Please people read the archives before posting here, we have discussed > all this long enough. > > Tuesday, November 14, 2006, 9:36:10 AM, you wrote: > > > The only issue with using \ is the fact that this is the escape > > character. If you are using PHP to create classes (collapsing complex > > classes into simpler ones, implementing a fake AOP), you have to > > remember to escape the escape. It just seems odd to re-use a symbol > > like this. A new symbol is better. IIHMY, I would use # and remove # > > from comments. # looks like a grid which can be thought of as a > > compartmentalisation process; i.e. grouping things together in their > > own little space - a perfect concept to explain namespaces. We already > > have singleline and block comments with // and /* ... */. Not really > > sure of the need of #. Of course, this would be an evern bigger BC. > > Even my own code uses #. > > > The triple colon (:::) is OK, but what happens during a mistype. Is > > there a possibility that :: and ::: COULD be used interchangably (an > > extreme example), producing working code? > > > > > On 14/11/06, Marcus Boerger <helly@php.net> wrote: > >> Hello Jessie, > >> > >> Tuesday, November 14, 2006, 5:00:42 AM, you wrote: > >> > >> > What does everyone else think? Are functions/constants inside namespaces > >> > really that critical? > >> > >> > Anyways, I just thought of a possible solution to the namespace > >> > separator issue, and if it's doable, then the double colon (::) can even > >> > be used and no conflicts would occur. It seems the biggest problem with > >> > handling namespaces is determining if a symbol is a class or namespace > >> > at compile-time. I am no expert in flex/bison, but I was thinking that a > >> > state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will > >> > return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on > >> > whether the symbol is known to be a class or namespace. The user will > >> > add either a "using" or "import" statement before the use of the symbol, > >> > and this will allow the parser to know what that symbol is in the > >> > compilation phase. As an example: > >> > >> > >> > // BEGIN CODE > >> > using namespace PEAR::File; > >> > $items = File::Find::glob( '!.*\.php$!', $dir, 'perl' ); > >> > // END CODE > >> > >> > >> > The first statement will add an entry into a hashtable (used during > >> > compilation) indicating that "PEAR", "PEAR::File", and "File" are > >> > namespaces ("File" will be imported in the current file only). When > >> > "File::Find::glob" is parsed, the compiler already knows that "File" is > >> > a namespace, so "Find" must be a class inside that namespace, and "glob" > >> > must be a static method. With this, functions and constants can easily > >> > be added inside namespaces, as the "using" or "import" statement will > >> > indicate to the parser which portion of the qualified name is a namespace. > >> > >> > Is this feasible in flex/bison? Let me know if anything needs clarification. > >> > >> Short: no > >> > >> Long: Please stop confusion here. We will get namespace innwith either ":::" > >> or "\" depending on who is going to implement it and what otherissues that > >> one will encounter. Later we may decide based on that implementation whether > >> it might be possible to use a different seperator. Btw, ifI wereto implement > >> namespacesupport today i would go with "\" as that is easier to translate to > >> a directory/file name in an __autoload function. While yesturday people > >> nearly convinced me (during the last conferences) that ":::" is closer to > >> the class/member seperator "::". > >> > >> best regards > >> marcus > >> > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > > > Best regards, > Marcus > >
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Marcus Börger

19 years ago
Hello Jessie, we already have consts in our classes, if you look close then you will see that the table does not conatain 'namespace:const' but only 'namespace:class' and still there are conflicts already. best regards marcus Sunday, November 12, 2006, 1:48:22 AM, you wrote:
> Hi Marcus,
> As I said, I wanted to only enable classes inside namespaces, and NOT > allow functions or constants. class::const would stay the same, so there > are no conflicts.
> Marcus Boerger wrote: >> Hello Jessie, >> >> sorry to say this but look at the following, keeping in mind that the >> whitespace is optional. >> >> $x = $foo ? class:const : $var // 1, 0 >> $x = $foo ? class:const : const; // 1, 0 >> $x = $foo ? class:const : class:const; // 1, 1 >> $x = $foo ? class:const : namespace:class:const; // 1, 2 >> $x = $foo ? namespace:class:const : $var; // 2, 0 >> $x = $foo ? namespace:class:const : const; // 2, 0 >> $x = $foo ? namespace:class:const : class:const; // 2, 1 >> $x = $foo ? namespace:class:const : namespace:class:const; // 2, 2 >> >> Feel free to continue that list, it has conflicts whatever you do. >> >> Saturday, November 11, 2006, 5:13:22 AM, you wrote: >> >>> Hello, >> >>> I haven't had time to work on my patch, but thinking about this some >>> more, I'm convinced namespaces should only contain classes. The only >>> problem that was present when permitting functions/constants to be >>> inside namespaces was the ambiguity in ternary expressions. By just >>> supporting classes inside namespaces, this issue would go away. Besides, >>> I'll dare say that most, if not all, the developers who want namespaces >>> will only group classes with it anyways, >> >>> Also, by only supporting classes, we can use ":" instead of the long >>> ":::" separator and everyone would be happy. >> >>> Last I checked, the only things that were pending on my patch were some >>> scoping issues which I had to fix. These are listed below. Once these >>> are done, the patch can be formally proposed. If anyone wants to take a >>> look at the patch so far and/or work on the remaining issues below, let >>> me know and I'll either post the patch or email it. >> >> >>> Pending: >> >>> 1) The extends clause should resolve imported class names. >> >>> import class ns:DateBase; >> >>> namespace ns{ class Date extends DateBase{} } >> >>> 2) To access a global symbol, use global:<class_name> syntax. >> >> I would prefer ':::'<class_name> or '\'<class_name> but that doesn't really >> matter as we have 'global' as a keyword already. >> >>> 3) Type hints should also consider imported classes. >> >>> 4) When an import is done (with alias or not), and a global class with >>> that same name exists, what is the desired behavior? Error? Global takes >>> precedence? >> >> Maybe this new discussion gave one hint. Aliases could be solved with a >> flag. Just copy the classwith a new name into the classlist again and flagit >> as copy. Maybe the original class gets a list of the copies of the copies a >> pointer to the original but that would be an implementation detail. As soon >> as that is done importdoes nothingelse then copying classes on a single >> class table. That said namespaces would, if after all, simply contain other >> copies to the original classes. In the extremecase we can start with >> namespaces only being a 'stupid' list. Reflection could then travers all >> classes to see in which namespaces it was registered. >> >> This btw would also fix 3) as the namespace seperator would be a normal >> sign in class lookup, it would simply be disallowed in definitions of >> class/interface/namespaces. >> >> Best regards, >> Marcus
Best regards, Marcus

Jessie Hernandez

19 years ago
Hi Marcus, Can you please clarify where the conflicts will occur if only classes are allowed in namespaces? Best regards, Jessie Hernandez Marcus Boerger wrote:

Jessie Hernandez

19 years ago
Marcus Boerger wrote:
> Hello Jessie, >
[snip]
> > Maybe this new discussion gave one hint. Aliases could be solved with a > flag. Just copy the classwith a new name into the classlist again and flagit > as copy. Maybe the original class gets a list of the copies of the copies a > pointer to the original but that would be an implementation detail. As soon > as that is done importdoes nothingelse then copying classes on a single > class table. That said namespaces would, if after all, simply contain other > copies to the original classes. In the extremecase we can start with > namespaces only being a 'stupid' list. Reflection could then travers all > classes to see in which namespaces it was registered. > > This btw would also fix 3) as the namespace seperator would be a normal > sign in class lookup, it would simply be disallowed in definitions of > class/interface/namespaces. >
Did not notice these further comments until now. Anyways, I originally implemented imports in this way (making copies in class_table and updating the reference count), but then I used another approach because then imports would be request-wide, and I wanted them to be file-specific only (yeah, I know the PHP6 meeting notes said they should be request-wide, but I see this causing many problems to the point where they cannot be used in order to guarantee safe code). Also, yes, ':' are not be allowed in either class or interface definitions, but they are included in the full name in class_table (e.g. "namespace_name:class_name"). This is how it is currently in my patch. Regards, Jessie Hernandez

Zeev Suraski

19 years ago
Sean, I think there are fair chances we'll introduce a very simplistic namespaces capability in PHP 6. It's pretty clear it will not have the notion of imports, and will be very much focused on classes (as opposed to functions and variables). In fact, I think you can very much imagine them as being a new way of writing a class name - just imagine you could specify a single colon (or whatever) in your class name. Anything beyond that is going to result in a significant slowdown of the execution engine *and* open a can of warms regarding scoping and symbol resolution. Just to clarify what Rasmus said (which is indeed what was agreed for PHP 6) - we will add namespaces to PHP 6 if we can find a good way of defining their semantics in the PHP spirit as well as an acceptable way to implement it. Those two reasons very much limit what we can or cannot do with namespaces in PHP, especially the first one. Zeev At 18:51 10/11/2006, Sean Coates wrote:

Richard Lynch

19 years ago
On Fri, November 10, 2006 10:51 am, Sean Coates wrote: +1 Given the usage of \ for string escaping, I'd have to vote for :::, I guess... But it wouldn't kill me if \ won the vote either.
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?