namespace improvements to be committed very soon - final review

17 years ago by Gregory Beaver — view source

unread

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.

multiple namespaces per file
use ::name;
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.

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

17 years ago by David Coallier — view source

unread

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.

multiple namespaces per file

use ::name;

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.

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

17 years ago by David Coallier — view source

unread

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.

multiple namespaces per file

use ::name;

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.

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

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

17 years ago by Sam Barrow — view source

unread

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

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.

multiple namespaces per file

use ::name;

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.

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

17 years ago by Gregory Beaver — view source

unread

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

17 years ago by Ken Stanley — view source

unread

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"

17 years ago by Gregory Beaver — view source

unread

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:

&lt;?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

17 years ago by johannes@php.net — view source

unread

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

17 years ago by Jani Taskinen — view source

unread

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.

multiple namespaces per file

use ::name;

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.

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/

17 years ago by Nathan Rixham — view source

unread

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

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.

multiple namespaces per file

use ::name;

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.

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

17 years ago by Marcus Boerger — view source

unread

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:

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.

multiple namespaces per file

use ::name;

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.

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

Best regards,
Marcus

17 years ago by Nathan Rixham — view source

unread

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:

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

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.

multiple namespaces per file

use ::name;

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.

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

Best regards,
Marcus

17 years ago by Andrew Rose — view source

unread

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

I think they call it moderation ;)

Andrew

17 years ago by Gregory Beaver — view source

unread

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

17 years ago by Stanislav Malyshev — view source

unread

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

17 years ago by Derick Rethans — view source

unread

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.

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

17 years ago by Jani Taskinen — view source

unread

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

17 years ago by Tim Starling — view source

unread

Jani Taskinen wrote:

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.

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

17 years ago by Jani Taskinen — view source

unread

Jani Taskinen wrote:

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.

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/

17 years ago by Tim Starling — view source

unread

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

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

-- Tim Starling

17 years ago by rich gray — view source

unread

If this suggestion from Jani is supported then all I can say is WTF a
bunch of prima donnas you internals/core devs are ... You don't want to
listen to your users who are in most cases NOT technically ignorant and
are in the trenches using your product and trying to make a living?
AFAIK no-one has forced you to develop the PHP codebase - kitchen/heat
are two words that come to mind. BTW the 'delete' option on your email
client is usually quite easy to use if you feel too much
feedback/suggestions from your users is upsetting your fragile nirvana.

PHP will go down the pan if you take that attitude .. remember it is
OPEN source

rant over
rich

17 years ago by scott.mcnaught@synergy8.com — view source

unread

This email thread is boring...

-----Original Message-----
From: rich gray [mailto:rich06@gmail.com]
Sent: Friday, 14 December 2007 12:17 AM
To: internals Mailing List
Subject: Re: [PHP-DEV] Internals read-only

PHP will go down the pan if you take that attitude .. remember it is
OPEN source

rant over
rich

17 years ago by rich gray — view source

unread

cott.mcnaught@synergy8.com wrote:

This email thread is boring...

yep - made even more so with your pointless comment

17 years ago by Andrew Rose — view source

unread

If this suggestion from Jani is supported then all I can say is WTF a
bunch of prima donnas you internals/core devs are ... You don't want to
listen to your users who are in most cases NOT technically ignorant and
are in the trenches using your product and trying to make a living?
AFAIK no-one has forced you to develop the PHP codebase - kitchen/heat
are two words that come to mind. BTW the 'delete' option on your email
client is usually quite easy to use if you feel too much
feedback/suggestions from your users is upsetting your fragile nirvana.

PHP will go down the pan if you take that attitude .. remember it is
OPEN source

I could not agree more Rich. I joined this list a few days ago after
starting to get into the core of PHP. Service to say I've not been
that impressed by the developers seemingly knee jerk reactions to some
list noise. The idea of shutting out anyone that's not a core dev is
impeding future generations of core developers when all this list
needs is a few people to moderate the noise, if indeed the consensus
is, it is too noisy.

I'll be honest, I feel very hesitant about posting anything to this
list after what I've seen these first few days. Seriously, is that
the message you want to send to future devs Jani?

Anyway, I'm new around here, so what does my opinion matter ;)

Andrew

17 years ago by Jani Taskinen — view source

unread

list noise. The idea of shutting out anyone that's not a core dev is
impeding future generations of core developers when all this list
needs is a few people to moderate the noise, if indeed the consensus
is, it is too noisy.

Any suggestions to make the list usable are welcome. But moderate it,
who would have the time and interest? (I don't)

I'll be honest, I feel very hesitant about posting anything to this
list after what I've seen these first few days. Seriously, is that
the message you want to send to future devs Jani?

If it makes people to think twice before pressing the "send" button,
then yes please, hopefully the message gets through.

Anyway, I'm new around here, so what does my opinion matter ;)

Opinions are like ***holes, everyone has one. :D

--Jani

17 years ago by Daniel Brown — view source

unread

I would say, if anything, there are two viable choices that

wouldn't adversely affect the PHP project:

1.) Have the Internals list read-only by all but (a)

developers/contributors and (b) people granted permission after having
posted useful information via the General list.

2.) Probably a better idea, just click that DELETE button on any

emails you don't feel like reading or responding to. I find that, in
a case study performed by myself just now, it takes me about a
half-second to achieve success with this method.

By silencing the masses, you offer them little choice but to find

an alternative solution. By closing out the discussions, even just
that much, you're turning PHP from a completely open source project,
in which all can participate and help mold the future of the language,
into a partially open source language. Yes, the source code itself,
as created by the core developers, will still be available to the
public at large.... but any discussion on implementation of new ideas
could only really be achieved through a fork of the project. Further,
how would you encourage new developers to join on if they couldn't
interact with - and get a feel for - those who actively post on this
list as it is? By only allowing them to read the threads posted,
without the ability to ask questions, it's like reading a manual. And
how often does the discussion in a published book evolve without
requiring a full reprint?

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

17 years ago by Paul Reinheimer — view source

unread

This is a subject I have discussed with several parties over the past year,
and I meet the fact that someone has finally suggested it publicly with
simultaneous relief and concern.

I see this move as having two primary effects, first to reduce the signal to
noise ratio on this list, which will hopefully improve the list for those
who use it to communicate on the future of the language, and those of use
who primarily read it to be kept in the loop (like myself). I think this
increase in efficacy would be good for those of you either working, or
volunteering your time to improve the language used by millions. The second
effect would be to make it harder for new people to join the team.
Regardless of the alternatives available (some discussion list rarely
touched by the core team, bug reports, blindly emailing people you've never
met before on the core team, etc) I think we can admit that this would
present an additional barrier to entry for people wishing to get involved in
the language.

I could be mistaken, but it looks to me as though the core team is
shrinking, both in head count and in hours spent coding. People move on to
new jobs, priorities change, etc. this is inevitable and I harbour no ill
will (in fact you all have my thanks for your time). Making the list read
only can help increase the efficiency of those still around, but how will
new blood enter the fold?

While I feel it is necessary to protect the time of the people improving the
language, I don't think this is a step you can take until a path for joining
this exclusive list is made clear, otherwise in a few years there might not
be a core team left.

Paul Reinheimer
(preinheimer@php.net)

17 years ago by Jani Taskinen — view source

unread

You're all just proving my point by replying to this stupid thread.
Thank you for that. :D

--Jani

I would say, if anything, there are two viable choices that
wouldn't adversely affect the PHP project:
1.) Have the Internals list read-only by all but (a)
developers/contributors and (b) people granted permission after having
posted useful information via the General list.
2.) Probably a better idea, just click that DELETE button on any
emails you don't feel like reading or responding to. I find that, in
a case study performed by myself just now, it takes me about a
half-second to achieve success with this method.
By silencing the masses, you offer them little choice but to find
an alternative solution. By closing out the discussions, even just
that much, you're turning PHP from a completely open source project,
in which all can participate and help mold the future of the language,
into a partially open source language. Yes, the source code itself,
as created by the core developers, will still be available to the
public at large.... but any discussion on implementation of new ideas
could only really be achieved through a fork of the project. Further,
how would you encourage new developers to join on if they couldn't
interact with - and get a feel for - those who actively post on this
list as it is? By only allowing them to read the threads posted,
without the ability to ask questions, it's like reading a manual. And
how often does the discussion in a published book evolve without
requiring a full reprint?

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

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

17 years ago by Richard Quadling — view source

unread

You're all just proving my point by replying to this stupid thread.
Thank you for that. :D

Spleen venting provides a calming effect on one's nerves.

--

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

17 years ago by Sean Coates — view source

unread

2.) Probably a better idea, just click that DELETE button on any
emails you don't feel like reading or responding to. I find that, in
a case study performed by myself just now, it takes me about a
half-second to achieve success with this method.

Against my better judgement, I'm jumping into this thread...

The problem with simply deleting mail you don't want to see is the
same as "just delete the spam you get"; it's one of signal-to-noise,
and the delete button worked until you get to that magical threshold
where it seems like all you're getting is junk and accidentally delete
the good stuff.

Take this thread for example. I find it very interesting as there are
many problems with PHP development as it currently stands (social
problems), and I've been working on coming up with a solution for just-
short of a year now (as many of the core members will attest, as I've
had offline, face-to-face conversations with them about this).

However, because Jani's original post was buried in the middle of YET
ANOTHER ridiculous debate on the "best" namespace operator, I actually
had to go back to my trash and dig out the original mail after seeing
Greg's reply and quoted text. I would never have seen it because I got
trigger happy because almost all of this thread was absolute junk.

I don't yet have a solution, not would I try to force it upon anyone,
but I do hope to propose one in the coming months. One that does
involve making internals read-only for non @php.net holders, but also
provides a clean and reasonable path for non-contributors to
contribute, and somehow weeds out the gimme-gimme freeloaders (note:
yes, there are non-@php.net holders that are not freeloaders).

17 years ago by Daniel Brown — view source

unread

2.) Probably a better idea, just click that DELETE button on any
emails you don't feel like reading or responding to. I find that, in
a case study performed by myself just now, it takes me about a
half-second to achieve success with this method.
[snip!]

However, because Jani's original post was buried in the middle of YET
ANOTHER ridiculous debate on the "best" namespace operator, I actually
had to go back to my trash and dig out the original mail after seeing
Greg's reply and quoted text. I would never have seen it because I got
trigger happy because almost all of this thread was absolute junk.

Yeah, I can empathize with that.  You have a point; I had to do

the same on my end. Still, even if it's reduced to only current PHP
developers (which I wholeheartedly think is a Bad Idea[TM]), you're
still going to have SNR issues because the developers will still be
going back-and-forth. It happens an ALL mailing lists --- even the
IETF lists (though there, at least, it's very self-regulated, at least
for now).

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

17 years ago by Steph Fox — view source

unread

C'mon guys, you're just not trying. Some of us stand to lose bets here...

2.) Probably a better idea, just click that DELETE button on any
emails you don't feel like reading or responding to. I find that, in
a case study performed by myself just now, it takes me about a
half-second to achieve success with this method.
[snip!]

However, because Jani's original post was buried in the middle of YET
ANOTHER ridiculous debate on the "best" namespace operator, I actually
had to go back to my trash and dig out the original mail after seeing
Greg's reply and quoted text. I would never have seen it because I got
trigger happy because almost all of this thread was absolute junk.

Yeah, I can empathize with that. You have a point; I had to do
the same on my end. Still, even if it's reduced to only current PHP
developers (which I wholeheartedly think is a Bad Idea[TM]), you're
still going to have SNR issues because the developers will still be
going back-and-forth. It happens an ALL mailing lists --- even the
IETF lists (though there, at least, it's very self-regulated, at least
for now).

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

17 years ago by Cristian Rodriguez — view source

unread

remember it is
OPEN source

yeah, start doing something useful then..

--
http://www.kissofjudas.net/

17 years ago by rich gray — view source

unread

Cristian Rodriguez wrote:

remember it is
OPEN source

yeah, start doing something useful then..

I just have ... so are you amongst the gilded core developers then?

17 years ago by Stanislav Malyshev — view source

unread

If this suggestion from Jani is supported then all I can say is WTF a
bunch of prima donnas you internals/core devs are ... You don't want to

I find it amusing how quick people are to jump into conclusions about a
group of people they don't even know based on one suggestion by one guy.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by rich gray — view source

unread

Stanislav Malyshev wrote:

If this suggestion from Jani is supported then all I can say is WTF a
bunch of prima donnas you internals/core devs are ... You don't want to

I find it amusing how quick people are to jump into conclusions about
a group of people they don't even know based on one suggestion by one
guy.
Snap. I find it amusing how people are quick to jump into conclusions
about something without reading the words... which is why I said -> is
supported <- in my OP

17 years ago by Ronald Chmara — view source

unread

If this suggestion from Jani is supported then all I can say is WTF
a bunch of prima donnas you internals/core devs are ... You don't
want to listen to your users who are in most cases NOT technically
ignorant and are in the trenches using your product and trying to
make a living?

My php.net dev number is #181. I've been actively, and passively,
involved with the project since 2000 or so, to the point where I'm
listed in the manual credentials. My first PHP project was converting
~14K files from PHP2/FI to PHP 3. So, I'd say that I've seen quite a
bit of the PHP history, and I've actually invested quite a chunk of
my life (and occasionally cash) into it.

I think what Jani is proposing is certainly worth consideration, to
cut down on external flames, rantings, musings, etc. ...

... But that's kind of how we've always done things on this project
(and it's apparently worked). Here's the normal workflow:

Some core dev, or some random end user, throws an idea out, and we
debate.

We argue.

We create differing implementations....

....and then we argue and debate some more.

(To paraphrase an old joke, if there are two PHP developers in a
room, there are at least 3 opinions.)

Differing voices are granted different weights, and the goal is that
the best ideas win.

Over the years, the 10-50 "core" PHP folks have gotten familiar with
the mindsets, strengths, and weaknesses of the (many) others in the
overall project. Voices from "outside" are not nearly as understood,
or as helpful, in advancing the debate, until they are understood
on the same level.

From what I gather, Jani wants to improve the quality of debate,
by reducing down the quantity of debate. That's simply the way Jani
thinks, and is part of what he brings, as a strength, to the larger
PHP team, in that he tries to focus on high-relevance targets. He's
not being a prima donna, he actually "doing his job", by trying to
make sure that the signal to noise ratio is low, and thus, core dev
is more efficient.

All that being said, I like Jani's idea.... to a certain extent. I
think that folks like Tim Starling should be allowed a voice in the
debates, as he's running a high-profile site, regardless of any
personal CVS activity. OTOH, foo@example.com may have a good point,
but have no idea of the underlying issues, and thus, contribute zero
intellectual content to the debate.

-Bop

17 years ago by Jochem Maas — view source

unread

Jani Taskinen wrote:

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.

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

most people reading the internals list already subscribed to general
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

17 years ago by Jani Taskinen — view source

unread

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!

We already have that, it's called "Feature/Change request" category in
bugs.php.net (which is of course ignored by everyone :)

--Jani

17 years ago by Tim Starling — view source

unread

Jani Taskinen wrote:

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!

We already have that, it's called "Feature/Change request" category in
bugs.php.net (which is of course ignored by everyone :)

Funny you should mention it, I was just trolling there an hour ago, with
a sarcastic feature request aimed at none other than yourself. Ignored
bug reports are better than ones shot on sight by trigger-happy admins.
At least they provide a forum for interested developers to discuss
solutions.

-- Tim Starling

17 years ago by Richard Quadling — view source

unread

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!

We already have that, it's called "Feature/Change request" category in
bugs.php.net (which is of course ignored by everyone :)

Oh. Really? I just added a useful one to fix the stupid way non
optional params are returned as False. Sure it is how it has always
been, but talk about counter-intuitive!

-t[-+] is the proposal by the way with -t- being the default as that
is what is currently done.

Wouldn't break backwards as -+ are not allowed in a param name.

--

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

17 years ago by Richard Quadling — view source

unread

most people reading the internals list already subscribed to general

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.

I'm SURE you are not implying that those that use the PHP language
(rather than the developers of the PHP language) are some how more
infantile and can only use crayons rather than wielding the fine
brushes that create the art of the language itself?

I would say that we (those that write PHP code) are your clients and
as the client is ALWAYS right, you should drop namespaces, add
discrete setters and getters to provide accessibility to class
properties and add 2 "" to the CreateProcess calls in the core to fix
to an old issue with the windows command line intepreter.

Then, we would have some progress.

;-{}}}

--

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

17 years ago by Olivier Hill — view source

unread

Why not just letting people with @php.net accounts post to the list as
well as people having the Zend Certification.

That would push the certification incentives to a new high. So you
either contribute or pay to write emails here :)

Olivier
btw: I'm joking, but yes, Jani is right on the SNR. Just don't know
the right way to fix this.

most people reading the internals list already subscribed to general

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.

I'm SURE you are not implying that those that use the PHP language
(rather than the developers of the PHP language) are some how more
infantile and can only use crayons rather than wielding the fine
brushes that create the art of the language itself?

I would say that we (those that write PHP code) are your clients and
as the client is ALWAYS right, you should drop namespaces, add
discrete setters and getters to provide accessibility to class
properties and add 2 "" to the CreateProcess calls in the core to fix
to an old issue with the windows command line intepreter.

Then, we would have some progress.

;-{}}}

17 years ago by Tim Starling — view source

unread

Olivier Hill wrote:

Why not just letting people with @php.net accounts post to the list as
well as people having the Zend Certification.

That would push the certification incentives to a new high. So you
either contribute or pay to write emails here :)

Olivier
btw: I'm joking, but yes, Jani is right on the SNR. Just don't know
the right way to fix this.

Just ignore it and get on with your work. That's the attitude I take
with my own project mailing lists. Threading helps, then you can ignore
replies to a non-interesting post. Make announcements when you've done
something significant. Discuss design decisions in private, say by IM,
with individuals or small groups who you know to be competent in the
specific area of interest. It's not a cabal, it's a do-ocracy. The
rabble doesn't make the decisions, because they don't write the code.

Public mailing lists are a pain, but they're a necessary pain. They help
to attract developers from the user community. They support juniors and
small-scale developers who ask simple questions and get help from others
who are on a similar level of competency. And they help to keep the user
community informed about upcoming changes. I'm not aware of any better
system.

-- Tim Starling

P.S.: Reply-To header munging is good too.

17 years ago by Jochem Maas — view source

unread

Richard Quadling wrote:

most people reading the internals list already subscribed to general

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.

I'm SURE you are not implying that those that use the PHP language
(rather than the developers of the PHP language) are some how more
infantile and can only use crayons rather than wielding the fine
brushes that create the art of the language itself?

no not at all, I was implying that the gross of the traffic on generals
are questions related to problems people have with stuff like register_globals - aka
full-on noobs, nothing wrong with that and actually I quite like to help most
of them (as do a fairly small but very active group of experienced, well-armed
phpers) ... it's just not the place to discussion the finer/complex details of
php functionality implementations. imho.

the crayon metaphor was actually an in-joke for the guys who are regulars on the
generals list.

I would say that we (those that write PHP code) are your clients and
as the client is ALWAYS right, you should drop namespaces, add

in this context I am the client - and I have been proven wrong many a time, even then
I'd rather not have my voice taken away completely ... and you never know if I might one day
say something useful. ;-)

17 years ago by Marco Tabini — view source

unread

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.

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.

17 years ago by Jani Taskinen — view source

unread

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

17 years ago by dz@bitxtender.com — view source

unread

Jani, if your blood pressure raises when reading "normal people's"
messages because your dictatorial mind cannot stand the opinion of
people that you regard inferior to yourself, my suggestion would be to
either go see a shrink or quit this open source project.

Here's hoping you will be able to sort your anger management issues
and eventually get off your high horse.

I wish you all the best,

David

Am 13.12.2007 um 14:08 schrieb Jani Taskinen:

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

17 years ago by Kristo Iila — view source

unread

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

17 years ago by johannes@php.net — view source

unread

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.

multiple namespaces per file

use ::name;

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

17 years ago by Saulo Vallory — view source

unread

I don't have php.net account, but I don't plan to just complaining... That's
why you don't see many emails from me... I would like to back to the main
discussion on this thread, specially to a point raised by Johannes. I really
don't think we need multiple namespaces per file and, in this case, the
braces are useless. And it seems we all agree that it's a good practice to
use only one namespace per file. Since, we allow multiple namespaces, we
should force a code clearer than the below code.

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

In this case, when the code doesn't follows the best practices, I think the
penalty of using braces is reasonable. Since the below code is easier to
maintain.

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

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.

multiple namespaces per file

use ::name;

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

--

Saulo Vallory
descolando! - www.descolando.com.br
LegoCode - www.legocode.com.br
Neoconn Networks - www.neoconn.com
+55 21 8182-0308

namespace improvements to be committed very soon - final review

$ 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

$ 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

--

I find it amusing how quick people are to jump into conclusions about a group of people they don't even know based on one suggestion by one guy.

--

--

$ 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

$ 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

I find it amusing how quick people are to jump into conclusions about a
group of people they don't even know based on one suggestion by one guy.