Everything

php

Home » Project » Newsgroups » php.internals » namespace improvements to be committed very soon - final review »

namespace improvements to be committed very soon - final review

php.internals

Greg Beaver

18 years ago

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

David Coallier

18 years ago

On Dec 11, 2007 6:13 PM, Gregory Beaver <greg@chiaraquartet.net> wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

David Coallier

18 years ago

On Dec 11, 2007 6:42 PM, David Coallier <davidc@php.net> wrote:

> On Dec 11, 2007 6:13 PM, Gregory Beaver <greg@chiaraquartet.net> wrote:
> > 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
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
> --
> 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

Sam Barrow

18 years ago

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

On Tue, 2007-12-11 at 18:42 -0500, David Coallier wrote:

Greg Beaver

18 years ago

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

Ken Stanley

18 years ago

On Dec 11, 2007 6:13 PM, Gregory Beaver <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 :)).

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

Greg Beaver

18 years ago

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

Johannes Schlueter

18 years ago

On Tue, 2007-12-11 at 22:33 -0600, Gregory Beaver wrote:

> 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

Jani Taskinen

18 years ago

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


On Tue, 2007-12-11 at 17:13 -0600, Gregory Beaver wrote:

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

Nathan Rixham

18 years ago

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:

Marcus Börger

18 years ago

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
>>
>>
>> On Tue, 2007-12-11 at 17:13 -0600, Gregory Beaver wrote:
>>> 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
>>>

Best regards,
Marcus

Nathan Rixham

18 years ago

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

Andrew Rose

18 years ago

On 12/12/2007, Nathan Rixham <nrixham@gmail.com> wrote:

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

Greg Beaver

18 years ago

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

Stanislav Malyshev

18 years ago

> 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

Derick Rethans

18 years ago

On Wed, 12 Dec 2007, Stanislav Malyshev wrote:

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

Jani Taskinen

18 years ago

On Thu, 2007-12-13 at 10:00 +0100, Derick Rethans 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.

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

Tim Starling

18 years ago

Jani Taskinen wrote:

> On Thu, 2007-12-13 at 10:00 +0100, Derick Rethans 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

Jani Taskinen

18 years ago

On Fri, 2007-12-14 at 00:35 +1100, Tim Starling wrote:

> Jani Taskinen wrote:
> > On Thu, 2007-12-13 at 10:00 +0100, Derick Rethans 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/

Tim Starling

18 years ago

Jani Taskinen wrote:

> On Fri, 2007-12-14 at 00:35 +1100, Tim Starling 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

rich gray

18 years ago

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

Unnamed Person

18 years ago

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

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

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

rich gray

18 years ago

cott.mcnaught@synergy8.com wrote:

> This email thread is boring...
>
>

yep - made even more so with your pointless comment

Andrew Rose

18 years ago

On 13/12/2007, rich gray <rich06@gmail.com> 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
> 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

Jani Taskinen

18 years ago

On Thu, 2007-12-13 at 14:56 +0000, Andrew Rose wrote:

> 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

Daniel Brown

18 years ago

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.

Cristian Rodriguez

18 years ago

> remember it is
> OPEN source

yeah, start doing something useful then..

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

rich gray

18 years ago

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?

Stanislav Malyshev

18 years ago

> 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

rich gray

18 years ago

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

Ronald Chmara

18 years ago

On Dec 13, 2007, at 6:17 AM, rich gray 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 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

Jochem Maas

18 years ago

Jani Taskinen wrote:

> On Thu, 2007-12-13 at 10:00 +0100, Derick Rethans 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.

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.

Jani Taskinen

18 years ago

On Thu, 2007-12-13 at 14:36 +0100, Jochem Maas 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 :)

--Jani

Tim Starling

18 years ago

Jani Taskinen wrote:

> On Thu, 2007-12-13 at 14:36 +0100, Jochem Maas 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

Richard Quadling

18 years ago

On 13/12/2007, Jani Taskinen <jani.taskinen@sci.fi> wrote:

> On Thu, 2007-12-13 at 14:36 +0100, Jochem Maas 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 :)

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

Richard Quadling

18 years ago

On 13/12/2007, Jochem Maas <jochem@iamjochem.com> wrote:

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

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

Olivier Hill

18 years ago

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.

On Dec 13, 2007 10:50 AM, Richard Quadling <rquadling@googlemail.com> wrote:

Tim Starling

18 years ago

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.

Jochem Maas

18 years ago

Richard Quadling wrote:

> On 13/12/2007, Jochem Maas <jochem@iamjochem.com> wrote:
>> 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.
>
> 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. ;-)

Marco Tabini

18 years ago

On 13-Dec-07, at 8:08 AM, Jani Taskinen wrote:

> On Thu, 2007-12-13 at 10:00 +0100, Derick Rethans 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.

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.

Jani Taskinen

18 years ago

On Thu, 2007-12-13 at 08:55 -0500, Marco Tabini wrote:

> 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

David Zülke

18 years ago

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:

Kristo Iila

18 years ago

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

Johannes Schlueter

18 years ago

Hi,

On Tue, 2007-12-11 at 17:13 -0600, Gregory Beaver wrote:

> 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

Saulo Vallory

18 years ago

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;
}
?>

On Dec 12, 2007 11:14 AM, Johannes Schlüter <johannes@php.net> wrote:

> Hi,
>
> On Tue, 2007-12-11 at 17:13 -0600, Gregory Beaver wrote:
> > 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
______________________________________

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