# Namespaces in PHP 6 - ++$take

- Thread: https://externals.io/message/26472
- Original archive: https://news-web.php.net/php.internals/26472
- Started by Sean Coates on 2006-11-10T16:51:25+00:00
- Messages: 55
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/26472.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #26472 — Sean Coates — 2006-11-10T16:51:25+00:00

URL: https://externals.io/message/26472#26472

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

---

## #26473 — Ilia Alshanetsky — 2006-11-10T17:27:13+00:00

URL: https://externals.io/message/26472#26473 · In reply to: #26472

> 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

---

## #26474 — Sean Coates — 2006-11-10T17:41:09+00:00

URL: https://externals.io/message/26472#26474 · In reply to: #26473

> 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

---

## #26475 — Andi Gutmans — 2006-11-10T17:49:13+00:00

URL: https://externals.io/message/26472#26475 · In reply to: #26472

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.

> -----Original Message-----
> From: Sean Coates [mailto:sean@caedmon.net] 
> Sent: Friday, November 10, 2006 8:51 AM
> To: internals
> Subject: [PHP-DEV] Namespaces in PHP 6 - ++$take
> 
> 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-cod
> e-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
> 
> --
>  To 
> unsubscribe, visit: http://www.php.net/unsub.php

---

## #26476 — Sebastian Bergmann — 2006-11-10T17:54:35+00:00

URL: https://externals.io/message/26472#26476 · In reply to: #26473

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

---

## #26477 — Ilia Alshanetsky — 2006-11-10T18:05:41+00:00

URL: https://externals.io/message/26472#26477 · In reply to: #26474

> 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

---

## #26479 — Ilia Alshanetsky — 2006-11-10T18:13:52+00:00

URL: https://externals.io/message/26472#26479 · In reply to: #26476

> Ilia Alshanetsky wrote:
> > […]
>
>  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

---

## #26480 — Sean Coates — 2006-11-10T18:19:51+00:00

URL: https://externals.io/message/26472#26480 · In reply to: #26477

> 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

---

## #26481 — Sebastian Bergmann — 2006-11-10T18:20:59+00:00

URL: https://externals.io/message/26472#26481 · In reply to: #26479

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

---

## #26482 — Daniel T. Gorski — 2006-11-10T18:23:58+00:00

URL: https://externals.io/message/26472#26482 · In reply to: #26477

> 

> > […]

> > […]

> 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

---

## #26483 — Ilia Alshanetsky — 2006-11-10T18:31:40+00:00

URL: https://externals.io/message/26472#26483 · In reply to: #26480

> > […]
> <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

---

## #26484 — Hans Lellelid — 2006-11-10T18:47:33+00:00

URL: https://externals.io/message/26472#26484 · In reply to: #26480

> > […]
>
> 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

---

## #26485 — Brian Moon — 2006-11-10T19:07:26+00:00

URL: https://externals.io/message/26472#26485 · In reply to: #26482

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

---

## #26486 — Hans Lellelid — 2006-11-10T19:30:55+00:00

URL: https://externals.io/message/26472#26486 · In reply to: #26485

Brian Moon wrote:
> > […]
>
> 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

---

## #26490 — Patrick Mueller — 2006-11-10T21:46:20+00:00

URL: https://externals.io/message/26472#26490 · In reply to: #26482

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

---

## #26491 — Tony Bibbs — 2006-11-10T21:57:27+00:00

URL: https://externals.io/message/26472#26491 · In reply to: #26490

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:
> Daniel T. Gorski wrote:
> 
> 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.

---

## #26492 — Lukas Kahwe Smith — 2006-11-10T22:01:47+00:00

URL: https://externals.io/message/26472#26492 · In reply to: #26490

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

---

## #26493 — Ilia Alshanetsky — 2006-11-10T22:05:06+00:00

URL: https://externals.io/message/26472#26493 · In reply to: #26491

> 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

---

## #26494 — Ilia Alshanetsky — 2006-11-10T22:07:38+00:00

URL: https://externals.io/message/26472#26494 · In reply to: #26492

> 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

---

## #26495 — Tony Bibbs — 2006-11-10T22:16:40+00:00

URL: https://externals.io/message/26472#26495 · In reply to: #26493

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

> 
> Ilia Alshanetsky

---

## #26496 — Patrick Mueller — 2006-11-10T22:23:38+00:00

URL: https://externals.io/message/26472#26496 · In reply to: #26491

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

---

## #26499 — Marcus Boerger — 2006-11-10T23:24:00+00:00

URL: https://externals.io/message/26472#26499 · In reply to: #26481

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:
> > […]

>  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

---

## #26502 — Marcus Boerger — 2006-11-10T23:31:56+00:00

URL: https://externals.io/message/26472#26502 · In reply to: #26486

Hello Hans,

Friday, November 10, 2006, 8:30:55 PM, you wrote:

> Brian Moon wrote:
> > […]

> 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

---

## #26510 — Robert Cummings — 2006-11-11T01:57:49+00:00

URL: https://externals.io/message/26472#26510 · In reply to: #26502

> Hello Hans,
> 
> Friday, November 10, 2006, 8:30:55 PM, you wrote:
> 
> > […]
> 
> > […]

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.          |
`------------------------------------------------------------'

---

## #26511 — David Lindstrom — 2006-11-11T03:34:55+00:00

URL: https://externals.io/message/26472#26511 · In reply to: #26472

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

---

Next page: https://externals.io/message/26472.md?page=2