[PHP-DEV] Namespaces in PHP 6 - ++$take

0 views
Skip to first unread message

Sean Coates

unread,
Nov 10, 2006, 11:54:16 AM11/10/06
to
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Ilia Alshanetsky

unread,
Nov 10, 2006, 12:29:02 PM11/10/06
to

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

unread,
Nov 10, 2006, 12:42:56 PM11/10/06
to
> 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

Andi Gutmans

unread,
Nov 10, 2006, 12:51:01 PM11/10/06
to
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:se...@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
>

Sebastian Bergmann

unread,
Nov 10, 2006, 12:56:55 PM11/10/06
to
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 Alshanetsky

unread,
Nov 10, 2006, 1:07:39 PM11/10/06
to

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

Ilia Alshanetsky

unread,
Nov 10, 2006, 1:15:43 PM11/10/06
to

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.

Sean Coates

unread,
Nov 10, 2006, 1:21:34 PM11/10/06
to
> 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

Daniel T. Gorski

unread,
Nov 10, 2006, 1:32:05 PM11/10/06
to
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

Ilia Alshanetsky

unread,
Nov 10, 2006, 1:33:41 PM11/10/06
to

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

unread,
Nov 10, 2006, 1:49:14 PM11/10/06
to

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

Brian Moon

unread,
Nov 10, 2006, 2:09:07 PM11/10/06
to
> 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

unread,
Nov 10, 2006, 2:32:59 PM11/10/06
to
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

Ilia Alshanetsky

unread,
Nov 10, 2006, 9:31:29 PM11/10/06
to

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

Patrick Mueller

unread,
Nov 10, 2006, 9:31:30 PM11/10/06
to
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...@us.ibm.com
IBM PHP Community Architect, IBM Research Triangle Park

Lukas Kahwe Smith

unread,
Nov 10, 2006, 9:31:32 PM11/10/06
to
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

Patrick Mueller

unread,
Nov 10, 2006, 9:32:47 PM11/10/06
to
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...@us.ibm.com
IBM PHP Community Architect, IBM Research Triangle Park

--

Ilia Alshanetsky

unread,
Nov 10, 2006, 9:35:10 PM11/10/06
to

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

unread,
Nov 10, 2006, 9:35:12 PM11/10/06
to

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

Marcus Boerger

unread,
Nov 10, 2006, 9:36:25 PM11/10/06
to
Hello Hans,

Very nice writing, I completley agree. The world is changing, so are
computer languages, so will we... :-)

Best regards,
Marcus

Tony Bibbs

unread,
Nov 10, 2006, 9:40:09 PM11/10/06
to
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.
>

--

Robert Cummings

unread,
Nov 10, 2006, 9:43:54 PM11/10/06
to
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. |
`------------------------------------------------------------'

David Lindstrom

unread,
Nov 10, 2006, 10:36:01 PM11/10/06
to
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" <se...@caedmon.net> skrev i meddelandet
news:4554AE0D...@caedmon.net...

--

Jessie Hernandez

unread,
Nov 10, 2006, 11:14:42 PM11/10/06
to
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

Marcus Boerger

unread,
Nov 11, 2006, 5:22:34 AM11/11/06
to
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

Jan Schneider

unread,
Nov 11, 2006, 7:52:28 AM11/11/06
to
Zitat von Hans Lellelid <ha...@velum.net>:

I couldn't agree more. There really wasn't an appealing reason to =20
switch to PHP5 too quickly for me, and force the users of our code to =20
do the same. There are a few reasons to switch to 5.2 probably, but =20
that's a different story.
But if there wasn't already Unicode support in PHP 6, having =20
namespaces was definitely a good reason to force our user to that =20
version.

Jan.

--=20
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/

Rasmus Lerdorf

unread,
Nov 11, 2006, 8:39:17 AM11/11/06
to
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

unread,
Nov 11, 2006, 11:10:16 AM11/11/06
to
> 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

David Zülke

unread,
Nov 11, 2006, 11:16:17 AM11/11/06
to


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.

Jessie Hernandez

unread,
Nov 11, 2006, 7:49:49 PM11/11/06
to
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.

--

Jessie Hernandez

unread,
Nov 11, 2006, 8:06:30 PM11/11/06
to
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

Stefan Walk

unread,
Nov 12, 2006, 6:13:19 AM11/12/06
to
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

Marcus Boerger

unread,
Nov 12, 2006, 9:04:56 AM11/12/06
to
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,
>>

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

Zeev Suraski

unread,
Nov 13, 2006, 7:06:56 AM11/13/06
to
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

Jessie Hernandez

unread,
Nov 13, 2006, 10:10:44 PM11/13/06
to
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:
> 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.
>
>

--

Jessie Hernandez

unread,
Nov 13, 2006, 10:11:18 PM11/13/06
to

Jessie Hernandez

unread,
Nov 13, 2006, 11:02:13 PM11/13/06
to
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:
> 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

--

Marcus Boerger

unread,
Nov 14, 2006, 3:09:59 AM11/14/06
to
Hello Jessie,

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

unread,
Nov 14, 2006, 3:44:56 AM11/14/06
to
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?


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

Marcus Boerger

unread,
Nov 14, 2006, 2:53:04 PM11/14/06
to
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.

Best regards,
Marcus

Lukas Kahwe Smith

unread,
Nov 15, 2006, 1:23:47 AM11/15/06
to
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

Derick Rethans

unread,
Nov 15, 2006, 3:38:13 AM11/15/06
to
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 Quadling

unread,
Nov 15, 2006, 3:41:20 AM11/15/06
to
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 <he...@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.
>

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

unread,
Nov 15, 2006, 2:50:50 PM11/15/06
to
Hello Richard,

as though what you say is true the rules are different inside {} inside "".

best regards
marcus

Best regards,
Marcus

Richard Lynch

unread,
Nov 15, 2006, 4:12:08 PM11/15/06
to
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?

Richard Lynch

unread,
Nov 15, 2006, 4:31:50 PM11/15/06
to
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.

Richard Lynch

unread,
Nov 15, 2006, 4:36:56 PM11/15/06
to
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!

Rasmus Lerdorf

unread,
Nov 16, 2006, 2:08:21 PM11/16/06
to
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

Ron Korving

unread,
Nov 17, 2006, 3:10:32 AM11/17/06
to
Why not add another bug-status called "incomplete" or something, and append
a standard message saying "Please study the bug-reporting guidelines in
order to write complete and accurate bug reports."? I think this tiny
addition to tagging something "bogus" would make a lot of bug reporters
happier and it might make them fix their bug report.

-- Ron


"Rasmus Lerdorf" <ras...@lerdorf.com> schreef in bericht
news:455CB6BD...@lerdorf.com...

Ilia Alshanetsky

unread,
Nov 17, 2006, 10:26:09 AM11/17/06
to
Majority of the "bogus" bugs are truly bogus, I see no reason to
change a perfectly valid term used to describe bugs.

Ilia Alshanetsky

Johannes Schlüter

unread,
Nov 17, 2006, 12:18:27 PM11/17/06
to
Hi,

that's the commonly used (and existing) "Feedback" status, but often
this won't lead to the required feedback.

johannes

Reply all
Reply to author
Forward
0 new messages