# namespace improvements to be committed very soon - final review

- Thread: https://externals.io/message/33942
- Original archive: https://news-web.php.net/php.internals/33942
- Started by Gregory Beaver on 2007-12-11T23:13:08+00:00
- Messages: 51
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/33942.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

---

## #33942 — Gregory Beaver — 2007-12-11T23:13:08+00:00

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

Hi,

I've been furiously working behind the scenes with Stas and Dmitry, and
have some enhancements to namespaces in the form of 2 patches.

1) multiple namespaces per file
2) use ::name;

1) multiple namespaces per file

This is implemented as such:

<?php
namespace one;
use Blah::A;
// code
namespace two;
use Foo::A;
?>

The example above shows that imported names are reset at each namespace
declaration.  There is no prohibition on this code:

<?php
namespace one; {
use Blah::A;
// code
}
namespace two; {
use Foo::A;
// code
}
?>

Users who wish to use brackets may do so.  The performance penalty
imposed by using brackets is minor for some cases, and for users who are
following the recommended practice of 1 namespace per file, the syntax
is ideal.

Patch is:

http://pear.php.net/~greg/namespace/PHP_5_3/multi.patch.txt
http://pear.php.net/~greg/namespace/PHP_6_0/multi.patch.txt

Note that non-namespaced code cannot be present in a file containing
namespaces.  For users who are bundling, this will mean you will need to
create 2 files, one with non-namespaced code, and one with namespaced
code.  This minor prohibition is a design decision, not a technical
problem in the implementation.

2) use ::name

This code:

<?php
namespace Whatever;
use MDB2; // import PEAR's ::MDB2 from global scope
$a = MDB2::connect();
?>

is currently impossible, which will make namespacing old code harder. 
The patch introduces this new syntax to import names from the global
namespace:

<?php
use ::MDB2, ::strlen as len;
?>

http://pear.php.net/~greg/namespace/PHP_5_3/use.patch.txt
http://pear.php.net/~greg/namespace/PHP_6_0/use.patch.txt

These patches are for review of both serious technical and serious
implementation issues.  In order to help move things along, I'd like to
define "serious" as something directly related to the implementation
that would cause a failure in PHP's ability to run scripts
deterministically, or some kind of memory leak/crash.

commit is planned for the next 24 hours or so, but of course any issues
found in review can be fixed.  The patches are short, so in the worst
case, reverting is not difficult.

Thanks,
Greg

---

## #33945 — David Coallier — 2007-12-11T23:42:31+00:00

URL: https://externals.io/message/33942#33945 · In reply to: #33942

> Hi,
>
> I've been furiously working behind the scenes with Stas and Dmitry, and
> have some enhancements to namespaces in the form of 2 patches.
>
> 1) multiple namespaces per file
> 2) use ::name;
>
> 1) multiple namespaces per file
>
> This is implemented as such:
>
> <?php
> namespace one;
> use Blah::A;
> // code
> namespace two;
> use Foo::A;
> ?>
>
> The example above shows that imported names are reset at each namespace
> declaration.  There is no prohibition on this code:
>
> <?php
> namespace one; {
> use Blah::A;
> // code
> }
> namespace two; {
> use Foo::A;
> // code
> }
> ?>
>

namespace name; {
...
}
 ??? You can already do that... it's just adding random { }


> Users who wish to use brackets may do so.  The performance penalty
> imposed by using brackets is minor for some cases, and for users who are
> following the recommended practice of 1 namespace per file, the syntax
> is ideal.
>
> Patch is:
>
> http://pear.php.net/~greg/namespace/PHP_5_3/multi.patch.txt
> http://pear.php.net/~greg/namespace/PHP_6_0/multi.patch.txt
>
> Note that non-namespaced code cannot be present in a file containing
> namespaces.  For users who are bundling, this will mean you will need to
> create 2 files, one with non-namespaced code, and one with namespaced
> code.  This minor prohibition is a design decision, not a technical
> problem in the implementation.
>
> 2) use ::name
>
> This code:
>
> <?php
> namespace Whatever;
> use MDB2; // import PEAR's ::MDB2 from global scope
> $a = MDB2::connect();
> ?>
>
> is currently impossible, which will make namespacing old code harder.
> The patch introduces this new syntax to import names from the global
> namespace:
>
> <?php
> use ::MDB2, ::strlen as len;
> ?>
>
> http://pear.php.net/~greg/namespace/PHP_5_3/use.patch.txt
> http://pear.php.net/~greg/namespace/PHP_6_0/use.patch.txt
>
> These patches are for review of both serious technical and serious
> implementation issues.  In order to help move things along, I'd like to
> define "serious" as something directly related to the implementation
> that would cause a failure in PHP's ability to run scripts
> deterministically, or some kind of memory leak/crash.
>
> commit is planned for the next 24 hours or so, but of course any issues
> found in review can be fixed.  The patches are short, so in the worst
> case, reverting is not difficult.
>
> Thanks,
> Greg
>
> --
> 
> 
>
>



-- 
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

---

## #33947 — David Coallier — 2007-12-11T23:45:28+00:00

URL: https://externals.io/message/33942#33947 · In reply to: #33945

> 
> > […]
>
> namespace name; {
> ...
> }
>  ??? You can already do that... it's just adding random { }
>
>
>
> > […]
>
>
>
> --
> David Coallier,
> Founder & Software Architect,
> Agora Production (http://agoraproduction.com)
> 51.42.06.70.18
>

Wow even nested namespaces are implemented!!!

namespace name;
{
    {
        {
            class Test { }
        }
    }
}

.......

use name as superName;
var_dump(new superName::Test());

Come on...


-- 
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

---

## #33956 — Sam Barrow — 2007-12-12T02:06:21+00:00

URL: https://externals.io/message/33942#33956 · In reply to: #33945

Is this patch going to be implemented in the PHP release?


> 
> > […]
> 
> namespace name; {
> ...
> }
>  ??? You can already do that... it's just adding random { }
> 
> 
> > […]
> 
> 
> 
> -- 
> David Coallier,
> Founder & Software Architect,
> Agora Production (http://agoraproduction.com)
> 51.42.06.70.18

---

## #33957 — Gregory Beaver — 2007-12-12T02:46:51+00:00

URL: https://externals.io/message/33942#33957 · In reply to: #33956

Sam Barrow wrote:
> Is this patch going to be implemented in the PHP release?

yes, these are patches against cvs.php.net php5 -r PHP_5_3 and HEAD

Greg

---

## #33958 — Ken Stanley — 2007-12-12T04:25:32+00:00

URL: https://externals.io/message/33942#33958 · In reply to: #33942

> The example above shows that imported names are reset at each namespace
> declaration.  There is no prohibition on this code:
>
> <?php
> namespace one; {
> use Blah::A;
> // code
> }
> namespace two; {
> use Foo::A;
> // code
> }
> ?>
>
> Users who wish to use brackets may do so.  The performance penalty
> imposed by using brackets is minor for some cases, and for users who are
> following the recommended practice of 1 namespace per file, the syntax
> is ideal.

My question is that if using the above code already incurs a perf penalty,
then why not just go ahead and include true support for braces in
namespaces. Unless there is an additional penalty that I'm missing, the only
difference between true braces and the above is that the above looks like a
cheap hack (note: the use the of phrase "cheap hack" is in no way meant to
demean the hard work of the people involved with the namespace
implementation, and is the sole opinion of the poster :)).



-- 
It looked like something resembling white marble, which was
probably what it was: something resembling white marble.
               -- Douglas Adams, "The Hitchhikers Guide to the Galaxy"

---

## #33959 — Gregory Beaver — 2007-12-12T04:33:57+00:00

URL: https://externals.io/message/33942#33959 · In reply to: #33958

Ken Stanley wrote:
>
>
> On Dec 11, 2007 6:13 PM, Gregory Beaver <greg@chiaraquartet.net
> <mailto:greg@chiaraquartet.net>> wrote:
>
>     The example above shows that imported names are reset at each
>     namespace
>     declaration.  There is no prohibition on this code:
>
>     <?php
>     namespace one; {
>     use Blah::A;
>     // code
>     }
>     namespace two; {
>     use Foo::A;
>     // code
>     }
>     ?>
>
>     Users who wish to use brackets may do so.  The performance penalty
>     imposed by using brackets is minor for some cases, and for users
>     who are
>     following the recommended practice of 1 namespace per file, the
>     syntax
>     is ideal. 
>
> My question is that if using the above code already incurs a perf
> penalty, then why not just go ahead and include true support for
> braces in namespaces. Unless there is an additional penalty that I'm
> missing, the only difference between true braces and the above is that
> the above looks like a cheap hack (note: the use the of phrase "cheap
> hack" is in no way meant to demean the hard work of the people
> involved with the namespace implementation, and is the sole opinion of
> the poster :)).
Because the performance penalty is unnecessary, just use 1 namespace per
file for your code.  Those who need to combine files are not doing it
for maintenance reasons.

Just to be clear, this code does *not* have a performance penalty:

<?php
namespace one;
use Blah::A;
//code
namespace two;
use Foo::A;
// code
?>

Any brackets adds another set of shift/reduce to the parser, regardless
of how the syntax of the language is defined.

Greg

---

## #33962 — Jani Taskinen — 2007-12-12T09:09:41+00:00

URL: https://externals.io/message/33942#33962 · In reply to: #33942

Nice to hear some work is done but I get very annoyed every time I see
the words "behind the scenes" (or something alike). I guess it was
because it's impossible to discuss anything on internals without the
noise coming from "outside"..? Could we finally make this list read-only
for every one but the @php.net people? I get enough spam already, spam
from this list is not something everyone should suffer from.

--Jani



> Hi,
> 
> I've been furiously working behind the scenes with Stas and Dmitry, and
> have some enhancements to namespaces in the form of 2 patches.
> 
> 1) multiple namespaces per file
> 2) use ::name;
> 
> 1) multiple namespaces per file
> 
> This is implemented as such:
> 
> <?php
> namespace one;
> use Blah::A;
> // code
> namespace two;
> use Foo::A;
> ?>
> 
> The example above shows that imported names are reset at each namespace
> declaration.  There is no prohibition on this code:
> 
> <?php
> namespace one; {
> use Blah::A;
> // code
> }
> namespace two; {
> use Foo::A;
> // code
> }
> ?>
> 
> Users who wish to use brackets may do so.  The performance penalty
> imposed by using brackets is minor for some cases, and for users who are
> following the recommended practice of 1 namespace per file, the syntax
> is ideal.
> 
> Patch is:
> 
> http://pear.php.net/~greg/namespace/PHP_5_3/multi.patch.txt
> http://pear.php.net/~greg/namespace/PHP_6_0/multi.patch.txt
> 
> Note that non-namespaced code cannot be present in a file containing
> namespaces.  For users who are bundling, this will mean you will need to
> create 2 files, one with non-namespaced code, and one with namespaced
> code.  This minor prohibition is a design decision, not a technical
> problem in the implementation.
> 
> 2) use ::name
> 
> This code:
> 
> <?php
> namespace Whatever;
> use MDB2; // import PEAR's ::MDB2 from global scope
> $a = MDB2::connect();
> ?>
> 
> is currently impossible, which will make namespacing old code harder. 
> The patch introduces this new syntax to import names from the global
> namespace:
> 
> <?php
> use ::MDB2, ::strlen as len;
> ?>
> 
> http://pear.php.net/~greg/namespace/PHP_5_3/use.patch.txt
> http://pear.php.net/~greg/namespace/PHP_6_0/use.patch.txt
> 
> These patches are for review of both serious technical and serious
> implementation issues.  In order to help move things along, I'd like to
> define "serious" as something directly related to the implementation
> that would cause a failure in PHP's ability to run scripts
> deterministically, or some kind of memory leak/crash.
> 
> commit is planned for the next 24 hours or so, but of course any issues
> found in review can be fixed.  The patches are short, so in the worst
> case, reverting is not difficult.
> 
> Thanks,
> Greg
> 
-- 
Patches/Donations: http://pecl.php.net/~jani/

---

## #33963 — Nathan Rixham — 2007-12-12T10:45:23+00:00

URL: https://externals.io/message/33942#33963 · In reply to: #33962

Surely the noise coming from outside are people's valid opinions? I mean 
it's the people making the noise who have to live with decisions made on 
the internals list, on a daily basis, and for most there income depends 
on it.

It's not just php you're discussing, it's thousands of developers 
working environment.. think of changes like this as somebody coming in 
and cleaning your pc and files structure up for you, yeah they're trying 
to help, but you had your files where you wanted them already..

No Offense and agreed on the spam issue!

Nathan

Jani Taskinen wrote:
> Nice to hear some work is done but I get very annoyed every time I see
> the words "behind the scenes" (or something alike). I guess it was
> because it's impossible to discuss anything on internals without the
> noise coming from "outside"..? Could we finally make this list read-only
> for every one but the @php.net people? I get enough spam already, spam
> from this list is not something everyone should suffer from.
> 
> --Jani
> 
> 
> 
> > […]

---

## #33964 — Marcus Boerger — 2007-12-12T11:07:17+00:00

URL: https://externals.io/message/33942#33964 · In reply to: #33963

Hello Nathan,

  if their income depends on it, hmm, I wonder, why the hell are they only
complaining? The amount of people being constructive and not actual
developers with a php.net account is close to zero. That is what Jani had in
mind. We have always been open and we have always gladly given account to
people who contributed.

marcus

Wednesday, December 12, 2007, 11:45:23 AM, you wrote:

> Surely the noise coming from outside are people's valid opinions? I mean 
> it's the people making the noise who have to live with decisions made on 
> the internals list, on a daily basis, and for most there income depends 
> on it.

> It's not just php you're discussing, it's thousands of developers 
> working environment.. think of changes like this as somebody coming in 
> and cleaning your pc and files structure up for you, yeah they're trying 
> to help, but you had your files where you wanted them already..

> No Offense and agreed on the spam issue!

> Nathan

> Jani Taskinen wrote:
> > […]




Best regards,
 Marcus

---

## #33965 — Nathan Rixham — 2007-12-12T11:19:40+00:00

URL: https://externals.io/message/33942#33965 · In reply to: #33964

> if their income depends on it, hmm, I wonder, why the hell are they
 > only complaining?
point well made

 > always been open and we have always gladly given account to
 > people who contributed.
and it's been well noticed, not to mention the amount of times you have 
to repeat yourself. Particularly over namespaces!

I used to work in a company that had been going for years, and they had 
something that affected staff called the "ibean", or "ay been" or 
translated "it's always been" - People don't like change. If only there 
was a way to filter through only constructive critism..

Regards Nathan

Marcus Boerger wrote:
> Hello Nathan,
> 
>   if their income depends on it, hmm, I wonder, why the hell are they only
> complaining? The amount of people being constructive and not actual
> developers with a php.net account is close to zero. That is what Jani had in
> mind. We have always been open and we have always gladly given account to
> people who contributed.
> 
> marcus
> 
> Wednesday, December 12, 2007, 11:45:23 AM, you wrote:
> 
> > […]
> 
> > […]
> 
> > […]
> 
> > […]
> 
> > […]
> 
> 
> 
> 
> Best regards,
>  Marcus

---

## #33967 — Andrew Rose — 2007-12-12T11:37:52+00:00

URL: https://externals.io/message/33942#33967 · In reply to: #33965

> > […]
> point well made
>
> > […]
> and it's been well noticed, not to mention the amount of times you have
> to repeat yourself. Particularly over namespaces!
>
> I used to work in a company that had been going for years, and they had
> something that affected staff called the "ibean", or "ay been" or
> translated "it's always been" - People don't like change. If only there
> was a way to filter through only constructive critism..

I think they call it moderation ;)

Andrew

---

## #33969 — johannes@php.net — 2007-12-12T13:05:06+00:00

URL: https://externals.io/message/33942#33969 · In reply to: #33959

> Any brackets adds another set of shift/reduce to the parser, regardless
> of how the syntax of the language is defined.

That's not all with that syntax.

<?php
{
    class foo { }
}
?>

Leads to a delayed declaration which is done at run-time, not at
compile-time - this might have bigger performance issues than just the
shift/reduce in the parser - especially with opcode caches.

 $ php53 -dvld.active=1 -dvld.execute=0 -r '{ class foo { }}'
Branch analysis from position: 0
Return found
filename:       Command line code
function name:  (null)
number of ops:  5
compiled vars:  none
line     #  op                           fetch          ext  return
operands
-------------------------------------------------------------------------------
   1     0  NOP                                                      
         1  EXT_STMT                                                 
         2  ZEND_DECLARE_CLASS                               null
'%00fooCommand+line+code0x998387c', 'foo'
         3  RETURN
null
         4* ZEND_HANDLE_EXCEPTION                                    

Class foo: [no user functions]

vs.

$ php53 -dvld.active=1 -dvld.execute=0 -r 'class foo { }'Branch analysis
from position: 0
Return found
filename:       Command line code
function name:  (null)
number of ops:  4
compiled vars:  none
line     #  op                           fetch          ext  return
operands
-------------------------------------------------------------------------------
   1     0  EXT_STMT                                                 
         1  NOP                                                      
         2  RETURN
null
         3* ZEND_HANDLE_EXCEPTION                                    


johannes

---

## #33971 — johannes@php.net — 2007-12-12T13:14:04+00:00

URL: https://externals.io/message/33942#33971 · In reply to: #33942

Hi,


> Hi,
> 
> I've been furiously working behind the scenes with Stas and Dmitry, and
> have some enhancements to namespaces in the form of 2 patches.
> 
> 1) multiple namespaces per file
> 2) use ::name;
> 
> 1) multiple namespaces per file
> 
> This is implemented as such:
> 
> <?php
> namespace one;
> use Blah::A;
> // code
> namespace two;
> use Foo::A;
> ?>

I don't care about multiple namespaces per file, but if we allow
multiple namespaces in one file we should also enforce these. If we
don't enforce the braces people will write code like above and that's
really bad for maintenance. (While it makes me even more happy that I
don't do consulting stuff anymore - I don't read other people's PHP code
anymore - but from that time I know that people will misuse such a
feature)

johannes

---

## #33977 — Gregory Beaver — 2007-12-12T16:43:47+00:00

URL: https://externals.io/message/33942#33977 · In reply to: #33962

Jani Taskinen wrote:
> Nice to hear some work is done but I get very annoyed every time I see
> the words "behind the scenes" (or something alike). I guess it was
> because it's impossible to discuss anything on internals without the
> noise coming from "outside"..? Could we finally make this list read-only
> for every one but the @php.net people? I get enough spam already, spam
> from this list is not something everyone should suffer from.

All I meant by "behind the scenes" was quite a bit of time using IM,
revising the patch and emailing back and forth to resolve obvious
problems before making a public proposal.  Surely we don't need public
feedback on half-baked ideas?

Incidentally, the multiple namespaces patch has been around for months,
first posted on the list, and the idea of use ::name and the problem of
not having it has been noted multiple times on the list.

Greg

---

## #33979 — Stanislav Malyshev — 2007-12-12T18:03:41+00:00

URL: https://externals.io/message/33942#33979 · In reply to: #33962

> Nice to hear some work is done but I get very annoyed every time I see
> the words "behind the scenes" (or something alike). I guess it was

It is much more efficient to communicate in person (preferably 
physically, but can be phone, IM, chat, etc.) than to write 
semi-anonymous mails to public list. There's no decision that would be 
taken unannounced, and all CVS is public of course, but I see no point 
of making public each minute detail of each private discussion. 
Especially that most of that, until some kind of common ground is 
reached, is of no particular use to others. That's like requiring people 
to commit code to CVS every 5 minutes, even if it's not finished.

> because it's impossible to discuss anything on internals without the
> noise coming from "outside"..? Could we finally make this list read-only
> for every one but the @php.net people? I get enough spam already, spam
> from this list is not something everyone should suffer from.

That's not the spam question. Talking directly to the person(s) is and 
would always be better than sending mails to a public list, from a ton 
of aspects. I see no reason to close the list, but I wouldn't expect all 
the discussions to happen *only* on the list. Of course, important 
things need to be discussed on the list, and they are.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #33985 — Kristo Iila — 2007-12-13T07:12:12+00:00

URL: https://externals.io/message/33942#33985 · In reply to: #33962

hello!

Jani Taskinen wrote:
> Nice to hear some work is done but I get very annoyed every time I see
> the words "behind the scenes" (or something alike). I guess it was
> because it's impossible to discuss anything on internals without the
> noise coming from "outside"..? Could we finally make this list read-only
> for every one but the @php.net people? I get enough spam already, spam
> from this list is not something everyone should suffer from.

I don't have a php.net mail address, but I would like to say, that 
please do make this list read only. Why? well, because I do make a 
living using php and thus I like to be up to date with things that are 
going on with its development, which is why I read the internals list.

But what I don't want to have to wade through, is opinions from people 
who don't know what they're talking about or maybe they do, but will 
never really do anything about it other than writing messages to the 
newsgroup. In my mind, opinions from people, who are not ready to follow 
them up with actions are much less important than those from the people 
that do.

Honestly, I just find it so hard to understand, how come people who have 
never done anything to improve php seem to think that their opinions 
have any weight in choosing the direction the language should take. I 
certainly would not expect anyone to care what I think about namespaces 
or late binding or whatever topic, unless I can back it up with patches.

Also, you might want to let messages through, that have patches attached 
to them, so newcomers still can get those in.

Oh, and thanks for all the hard work in making a great programming 
language that I love to use every day.

Kristo Iila

---

## #33986 — Derick Rethans — 2007-12-13T09:00:28+00:00

URL: https://externals.io/message/33942#33986 · In reply to: #33979

> > […]
> 
> That's not the spam question. Talking directly to the person(s) is and 
> would always be better than sending mails to a public list, from a ton 
> of aspects. I see no reason to close the list, but I wouldn't expect 
> all the discussions to happen *only* on the list. Of course, important 
> things need to be discussed on the list, and they are.

Although I don't really care about this specific issue, I do think that 
all the "spam" on the list drives people quicker to private discussions. 
I do think that in most (if not all) cases where e-mail is used to 
discuss PHP issues, the lists should be used. Especially when it's about 
redoing, say, a database abstraction layer. Private discussions are not 
a good idea, for just as many reasons as you probably can up with for 
saying that "sending mails to the public list" is not a good idea. But 
this is an Open Source project, and transparency is very important. 
Lately this has been slipping away, which I think is very sad.

To to get back to the point of the noise on the lists - it's getting out 
of hand, and I am afraid that if we don't solve this any time soon, the 
lists will be useless for any sort of decent discussion and promoting 
even more secret cults.

regards,
Derick

---

## #33990 — Jani Taskinen — 2007-12-13T13:08:03+00:00

URL: https://externals.io/message/33942#33990 · In reply to: #33986

> To to get back to the point of the noise on the lists - it's getting out 
> of hand, and I am afraid that if we don't solve this any time soon, the 
> lists will be useless for any sort of decent discussion and promoting 
> even more secret cults.

There's already public list, it's called "php-general". So just
unsubscribe all people from this list and subscribe all @php.net addies
only. 

Another solution is to simply stop discussing things and just commit. :)

Same worked for bugs: my blood pressure got normal again since I've
ignored the reports. :D

--Jani

---

## #33991 — Tim Starling — 2007-12-13T13:35:52+00:00

URL: https://externals.io/message/33942#33991 · In reply to: #33990

Jani Taskinen wrote:
> 
>   
> > […]
>
> There's already public list, it's called "php-general". So just
> unsubscribe all people from this list and subscribe all @php.net addies
> only. 
>   
If you unsubscribe everyone, we won't be able to read it. I only 
subscribed to this list after I got frustrated with the NNTP server 
constantly giving connection refused errors. Being subscribed is 
apparently the only convenient way to read the list regularly.

-- Tim Starling

---

## #33992 — Jochem Maas — 2007-12-13T13:36:38+00:00

URL: https://externals.io/message/33942#33992 · In reply to: #33990

Jani Taskinen wrote:
> 
> > […]
> 
> There's already public list, it's called "php-general". So just
> unsubscribe all people from this list and subscribe all @php.net addies
> only. 

that's doesn't seem like a good idea imho.

1. most people reading the internals list already subscribed to general
2. general is in no way suitable for the kind of discussion currently
occuring on internals - the difference between internals and general is akin
to the difference between fine art and drawing with crayons.

if the consensus amongst devs is that no-one other than devs have any
right to offer input to internal implementation discussions then make
internals readonly for every other than the devs. personally I think that
just doing that is not good for the cause at all - there are plenty of people
using php that do offer worthwhile feedback to implementation discussions,
excluding them will just lower the quality and usefulness of the stuff
your releasing.

my suggestion would be to split internals into 2 lists

internals 		- readonly except for devs
internals-discussion 	- anyone may post

of course this would only work if devs actually took the internals-discussion
list seriously which given the current sentiments floating about seems unlikely,
don't get me wrong I understand your sentiment!

alternatively moderation could be applied to internals, whereby dev can post unmoderated
and everyelse has to go through a filter - ofcourse you have to find a couple of people
to do the moderation, my guess is that it would not be too hard to find a few intelligent,
interested & knowledgable people from within the php community who would be willing to
help the devs in this way.

I would hazard to say that php is becoming a victim of it's own success in
this regard - to really tackle the issue would probably require the implementation
of a more structured proposal/implementation/release process ... I will grant that
that is a mammoth task to undertake!

> 
> Another solution is to simply stop discussing things and just commit. :)

somehow I doubt that that strategy will help to improve php's reputation for
stability and usefulness (percieved or otherwise) especially with regard to
the 'enterprise market' which is increasing being aimed at.

> 
> Same worked for bugs: my blood pressure got normal again since I've
> ignored the reports. :D
> 
> --Jani

---

## #33993 — Jani Taskinen — 2007-12-13T13:46:11+00:00

URL: https://externals.io/message/33942#33993 · In reply to: #33991

> Jani Taskinen wrote:
> > […]
> If you unsubscribe everyone, we won't be able to read it. I only 
> subscribed to this list after I got frustrated with the NNTP server 
> constantly giving connection refused errors. Being subscribed is 
> apparently the only convenient way to read the list regularly.

Use this: http://news.php.net/php.internals

And no, it doesn't need to be convenient as long as it's public. :)

-- 
Patches/Donations: http://pecl.php.net/~jani/

---

## #33994 — Tim Starling — 2007-12-13T13:47:32+00:00

URL: https://externals.io/message/33942#33994 · In reply to: #33993

Jani Taskinen wrote:
> 
>   
> > […]
>
> Use this: http://news.php.net/php.internals
>
> And no, it doesn't need to be convenient as long as it's public. :)
>   

That's the NNTP server I mean. It seems to be chronically overloaded.

-- Tim Starling

---

## #33995 — Marco Tabini — 2007-12-13T13:55:25+00:00

URL: https://externals.io/message/33942#33995 · In reply to: #33990

> 
> > […]
>
> There's already public list, it's called "php-general". So just
> unsubscribe all people from this list and subscribe all @php.net  
> addies
> only.

I am just a lurker, so take this with the due grain of salt, but  
simply making internals@ read-only is just going to drive people to  
contact the core team members directly (thus likely *increasing* your  
blood pressure :-)). I think you need to provide people with some way  
of interacting without unleashing chaos on the development process;  
php-general, IMHO, is not the place for that kind of discussion,  
because people there are mostly looking for assistance with the use of  
PHP, rather than attempting to influence the development process.


Mt.

---

## #33996 — Jani Taskinen — 2007-12-13T13:58:37+00:00

URL: https://externals.io/message/33942#33996 · In reply to: #33995

> I am just a lurker, so take this with the due grain of salt, but  
> simply making internals@ read-only is just going to drive people to  
> contact the core team members directly (thus likely *increasing* your  
> blood pressure :-)). I think you need to provide people with some way  
> of interacting without unleashing chaos on the development process;  
> php-general, IMHO, is not the place for that kind of discussion,  
> because people there are mostly looking for assistance with the use of  
> PHP, rather than attempting to influence the development process.

IMNSHO contacting core members directly is the only way to really make
them interested AND to actually notice the idea. At least with the list
being what it's like right now. :)

--Jani

---

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