Re: [PHP-DEV] Give the Language a Rest motion

[Sebastian Bergmann]

Zeev Suraski schrieb:
> we're still heatedly debating on adding new syntactical, core level 
> features.

 Apart from namespaces, I can't think of any other "syntactical core
 level feature" missing that could not be implemented as an extension.

 Sara and Marcus have already shown (with the Operator and the SPL_Types
 extensions, respectively) that new language features (operator
 overloading and autoboxing, for example) can be added to PHP without
 having to touch PHP itself.

-- 
Sebastian Bergmann  http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

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

Re: [PHP-DEV] Give the Language a Rest motion

[Zeev Suraski]

Good response, but it wasn't even 30 minutes :)

Zeev

At 13:07 09/03/2006, Sebastian Bergmann wrote:

Zeev Suraski schrieb:
> we're still heatedly debating on adding new syntactical, core level
> features.

 Apart from namespaces, I can't think of any other "syntactical core
 level feature" missing that could not be implemented as an extension.

 Sara and Marcus have already shown (with the Operator and the SPL_Types
 extensions, respectively) that new language features (operator
 overloading and autoboxing, for example) can be added to PHP without
 having to touch PHP itself.

--
Sebastian Bergmann  http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

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


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

Re: [PHP-DEV] Give the Language a Rest motion

[David Zülke]

I might be missing something here, but I thought the people  
discussing things on this list are members of the user base. Thus,  
they likely propose syntax changes and improvements because they need  
them.


I have to say that I don't really get that argument some people bring  
forward over and over again: "adding new features makes PHP more  
difficult for beginners". Oh. Late static binding makes code  
difficult to understand. Namespaces make code difficult to  
understand. That's nonsense really. Take your average PHP beginner,  
show him some code where iterators or __get/__set/__call are used and  
ask him what's going on. You'd get the same answer.


The web is one of the most quickly changing areas in computer  
technology. PHP, being primarily a language for web sites and  
applications, has to change constantly in order to be able to remain  
competitive. And it still has a long way to go. Unicode and  
Namespaces/Packages support are absolutely essential in large  
environments where interoperability is essential. Until that happens,  
PHP won't be the language of choice for a good number of large (and  
small) enterprises when it comes to implementing certain  
applications. You can't solve this problem only by producing  
frameworks or announcing one-click installers with Oracle support.  
It's the language itself that also has to change so it can rise to  
new challenges.


And last but not least, the pursuit of innovation, percection,  
advancement is what defines mankind. You shouldn't really try to stop  
that. It must be in the very interest of any language, even PHP, to  
get better over time.


- David



Am 09.03.2006 um 11:57 schrieb Zeev Suraski:


I'd like to raise a motion to 'Give the Language a Rest'.

Almost a decade since we started with the 2nd iteration on the  
syntax (PHP 3), and 2 more major versions since then, and we're  
still heatedly debating on adding new syntactical, core level  
features.


Is it really necessary?  I'd say in almost all cases the answer's  
no, and a bunch of cases where a new feature could be useful does  
not constitute a good enough reason to add a syntax level feature.   
We might have to account for new technologies, or maybe new ways of  
thinking that might arise, but needless to say, most of the stuff  
we've been dealing with in recent times doesn't exactly fall in the  
category of cutting edge technology.


My motion is to make it much, much more difficult to add new syntax- 
level features into PHP.  Consider only features which have  
significant traction to a large chunk of our userbase, and not  
something that could be useful in some extremely specialized edge  
cases, usually of PHP being used for non web stuff.


How do we do it?  Unfortunately, I can't come up with a real  
mechanism to 'enforce' a due process and reasoning for new features.


Instead, please take at least an hour to bounce this idea in the  
back of your mind, preferably more.  Make sure you think about the  
full context, the huge audience out there, the consequences of   
making the learning curve steeper with every new feature, and the  
scope of the goodness that those new features bring.  Consider how  
far we all come and how successful the PHP language is today, in  
implementing all sorts of applications most of us would have never  
even thought of when we created the language.


Once you're done thinking, decide for yourself.  Does it make sense  
to be discussing new language level features every other week?  Or  
should we, perhaps, invest more in other fronts, which would be  
beneficial for a far bigger audience.  The levels above -  
extensions to keep with the latest technologies, foundation  
classes, etc.  Pretty much, the same direction other mature  
languages went to.


To be clear, and to give this motion higher chances of success, I'm  
not talking about jump.  PHP can live with jump, almost as well as  
it could live without it :)  I'm talking about the general sentiment.


Zeev

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




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

Re: [PHP-DEV] Give the Language a Rest motion

[Brian Moon]

Zeev Suraski wrote:
> I'd like to raise a motion to 'Give the Language a Rest'.

+1

Brian Moon
dealnews.com
--
How to go broke saving money.
http://dealnews.com/

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

Re: [PHP-DEV] Give the Language a Rest motion

[Sara Golemon]

Apart from namespaces, I can't think of any other "syntactical core
level feature" missing that could not be implemented as an extension.


Goto can't...

Well, okay fine.  It can, but at a significantly greater cost and 
complexity.  By that token namespaces can be done in an extension too (You 
just REALLY wouldn't like it).



I'd like to raise a motion to 'Give the Language a Rest'.

I have to disagree.  Unicode support is a syntax level feature and that's 
the flagship feature of the PHP6 release.  Exceptions are a syntax level 
feature and that was one of the shining points of PHP5.  Perhaps what it's 
time for is recognizing that PHP is still an evolving language.


Many (most) of these interminable threads are pointless deadends, but that 
doesn't make the one good idea in there not worth discussing.  It also 
doesn't make the bad ideas not worth discussing because that's how you sort 
them out.



Or should we, perhaps, invest more in other
fronts, which would be beneficial for a far bigger
audience.  The levels above - extensions to keep
with the latest technologies, foundation classes, etc.

I couldn't agree more.  That's why operator is an extension and not a 
proposed engine patch.  However, while ZE does a commendable job at exposing 
its internals to manipulation there are some shortcomings.  For example: My 
request last month for a modified or split comparison opcode to distinguish 
greater-than from less-than.  You made some good points there about 
reconsidering how important it really was to know, and I do still plan to 
work those in, but this does serve as a good example of how the extension 
layer isn't _always_ enough.


The inability to inject tokens and expressions into the lexer and parser is 
another limitation on what can be done from extensions in terms of syntax 
level features.  Yes, I know this is more of a problem with bison and flex 
than with the design of ZE, but that doesn't make it any less bothersome.


-Sara 


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

Re: [PHP-DEV] Give the Language a Rest motion

[Sebastian Bergmann]

Sara Golemon schrieb:
> The inability to inject tokens and expressions into the lexer and 
> parser is another limitation on what can be done from extensions in 
> terms of syntax level features.  Yes, I know this is more of a problem 
> with bison and flex than with the design of ZE, but that doesn't make 
> it any less bothersome.

 Do other compiler tools allow this?

-- 
Sebastian Bergmann  http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

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

Re: [PHP-DEV] Give the Language a Rest motion

[Jared White]

Sure, after you folks implement named parameters. :)

*ducks and tries to hide*

Jared


On Mar 9, 2006, at 2:57 AM, Zeev Suraski wrote:


I'd like to raise a motion to 'Give the Language a Rest'.


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

Re: [PHP-DEV] Give the Language a Rest motion

[Sara Golemon]

The inability to inject tokens and expressions into the lexer and
parser is another limitation on what can be done from extensions in
terms of syntax level features.  Yes, I know this is more of a problem
with bison and flex than with the design of ZE, but that doesn't make
it any less bothersome.


Do other compiler tools allow this?

I've heard second hand that lemon does.  But I'm quite certain that 
rewriting the lexer/parser is not at the top of the list of productive ways 
to advance the language.


-Sara 


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

Re: [PHP-DEV] Give the Language a Rest motion

[Stanislav Malyshev]

DZ>>The web is one of the most quickly changing areas in computer technology.
DZ>>PHP, being primarily a language for web sites and applications, has to
DZ>>change constantly in order to be able to remain competitive. And it still

I don't see any real connection between new Web technologies and changing 
PHP language. Most of the new technologies are not related to any language 
features. If you want to support AJAX, you don't need any change in the 
syntax of the language itself - you need good extension and yes, framework 
- or standard library - support, so it would be easy to implement this 
technology. I have yet to see one example of new Web technology that is 
not possible to implement using existing PHP syntax, especially if we talk 
about PHP5 OO capabilities. While there definitely can be improvements 
made to PHP (and I think, for example, packages issue is one of the areas 
this might happen), changing language is much more significant step than 
adding an extension and needs much more thorough thinking through.

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115

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

Re: [PHP-DEV] Give the Language a Rest motion

[Steph Fox]

I'd like to raise a motion to 'Give the Language a Rest'.


Tired inbox? :)

Almost a decade since we started with the 2nd iteration on the syntax (PHP 
3), and 2 more major versions since then, and we're still heatedly 
debating on adding new syntactical, core level features.


Is it really necessary?  I'd say in almost all cases the answer's no, and 
a bunch of cases where a new feature could be useful does not constitute a 
good enough reason to add a syntax level feature.  We might have to 
account for new technologies, or maybe new ways of thinking that might 
arise, but needless to say, most of the stuff we've been dealing with in 
recent times doesn't exactly fall in the category of cutting edge 
technology.


I think that's a Good Thing[TM]. Today's cutting edge technology can easily 
become tomorrow's partially-used banana in the pocket of history. Remember 
the transputer?


My motion is to make it much, much more difficult to add new syntax-level 
features into PHP.  Consider only features which have significant traction 
to a large chunk of our userbase, and not something that could be useful 
in some extremely specialized edge cases, usually of PHP being used for 
non web stuff.


TBH I'd say _generally_ this happens anyway. There isn't a lot of argument 
over 'edge case' changes, although there might be a number of requests for 
them (the perennial issue of memory usage in long-running CLI scripts 
springs instantly to mind). It's pretty rare to see anything new go into the 
Engine that comes under the heading of 'general-purpose language' rather 
than 'language for the web'.


How do we do it?  Unfortunately, I can't come up with a real mechanism to 
'enforce' a due process and reasoning for new features.


We usually have you and Rasmus rather than a mechanism :)  But let's assume 
we didn't, let's say you wanted to drop out of PHP development altogether 
and go raise chili peppers or whatever. The obvious thing would be to write 
some charter in stone.


Instead, please take at least an hour to bounce this idea in the back of 
your mind, preferably more.  Make sure you think about the full context, 
the huge audience out there, the consequences of  making the learning 
curve steeper with every new feature, and the scope of the goodness that 
those new features bring.  Consider how far we all come and how successful 
the PHP language is today, in implementing all sorts of applications most 
of us would have never even thought of when we created the language.


This would be the problem when it came to writing some charter in stone. 
Something that seems irrelevant now, might not be so in the future. Sara 
pointed to Unicode and exceptions as being cases in point; I personally 
don't have any vested interest in exceptions, but I know my life's going to 
be made easier by having integral Unicode support, and I know a lot of other 
PHP users are in that particular boat too. If there'd been a 'don't touch 
the Engine' rule writ in stone, would that option even have come under 
discussion? You're basically preventing evolution when you make hard rules.


Once you're done thinking, decide for yourself.  Does it make sense to be 
discussing new language level features every other week?  Or should we, 
perhaps, invest more in other fronts, which would be beneficial for a far 
bigger audience.  The levels above - extensions to keep with the latest 
technologies, foundation classes, etc.  Pretty much, the same direction 
other mature languages went to.


Perhaps there could be just the one hard rule. 'If it's possible to 
implement it as an extension, do so.' There'd be nothing to prevent 
co-opting essential functionality into the core, but also nothing preventing 
fly-by-night technologies from having support in PHP. The biggest problem 
there is that it doesn't give webhost users a fair crack because changing 
hosts means you risk losing a package or two; and the ability to write 
portable applications is affected in the same way. But this isn't about the 
language itself any more...


To be clear, and to give this motion higher chances of success, I'm not 
talking about jump.  PHP can live with jump, almost as well as it could 
live without it :)  I'm talking about the general sentiment.


Zeev

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


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

Re: [PHP-DEV] Give the Language a Rest motion

[Benj Carson]

> How do we do it?  Unfortunately, I can't come up with a real mechanism
> to 'enforce' a due process and reasoning for new features.

One mechanism that the MapServer project[1] has adopted is that all "major" 
features require an RFC before they are accepted and implemented.  Whoever 
is proposing the feature or change writes the RFC, which outlines what the 
impact of the change will be on users, how much code it touches, whether 
there are any BC breaks, etc.  Once the RFC is finalised, the core group of 
developers vote on the RFC and if the vote carries the feature is 
implemented.  (There's more to it than that, but this is the basic idea.  
See [2] for the full policy.)

Writing the RFC helps the person requesting the feature to stop and think 
about the implications of the change and to identify any potential 
technical hurdles before plowing into the code.  It also helps everyone 
else by having a concise, concrete description of the proposed feature that 
can be referred to during discussions.  When the feature is debated on 
their dev list everyone is one the same page.  Any changes or suggestions 
that come up during discussion can be included in the RFC.

Another benefit of this policy is that it increases the legitimacy of the 
project in corporate settings.  The so-called "Enterprise User" can point 
to it and say, "Hey, here's how these guys make decisions, it makes sense.  
My manager will like that".

The drawback to this scheme is that not many programmers like writing design 
documents, and would much rather just bang away at code.  This could have 
the effect of deterring potential contributors.  (That said, I haven't 
personally had any problem submitting patches to Mapserver.)

Anyway, just something to consider from a list-lurker...  PHP is a much 
bigger project than MapServer, so having a process as structured as theirs 
might not be feasible.  However, requiring RFCs for core language changes 
might be a good compromise between trying to implement any and every fancy 
new language feature and stopping core language development altogether.


Benj Carson

[1] http://mapserver.gis.umn.edu/
[2] http://mapserver.gis.umn.edu/development/rfc/ms-rfc-1/

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

Re: [PHP-DEV] Give the Language a Rest motion

[Lukas Smith]

Steph Fox wrote:

Perhaps there could be just the one hard rule. 'If it's possible to 
implement it as an extension, do so.' There'd be nothing to prevent 
co-opting essential functionality into the core, but also nothing 
preventing fly-by-night technologies from having support in PHP. The 
biggest problem there is that it doesn't give webhost users a fair crack 
because changing hosts means you risk losing a package or two; and the 
ability to write portable applications is affected in the same way. But 
this isn't about the language itself any more...


Actually there is a danger in making all too many different syntax 
enhancing extensions public:

Language fragmentation.

At some point some of these extensions might become incompatible with 
eachother. It just seems to me like a syntax adding extension is a 
different beast to handle than one that adds new syntax from system 
administrators/shared hosters perspective.


regards,
Lukas

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

Re: [PHP-DEV] Give the Language a Rest motion

[Marcus Boerger]

Hello Sara,

  but if we were moving from flex to re2c for that tokenizing scripts we'd
get a nice speed boost, too. Typically re2c based scanners are 2 to 3 times
faster than lex based ones. And oh-re2c allows unicode scanning (2 byte
input) and you can use the same .re to generate two .c files if necessary.

best regards
matcus

Thursday, March 9, 2006, 6:44:45 PM, you wrote:

>>> The inability to inject tokens and expressions into the lexer and
>>> parser is another limitation on what can be done from extensions in
>>> terms of syntax level features.  Yes, I know this is more of a problem
>>> with bison and flex than with the design of ZE, but that doesn't make
>>> it any less bothersome.
>>
>> Do other compiler tools allow this?
>>
> I've heard second hand that lemon does.  But I'm quite certain that 
> rewriting the lexer/parser is not at the top of the list of productive ways 
> to advance the language.

> -Sara 




Best regards,
 Marcus

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

Re: [PHP-DEV] Give the Language a Rest motion

[Zeev Suraski]

No speed boost with opcode caches, which will be bundled in PHP 6 :)

Zeev

At 01:15 10/03/2006, Marcus Boerger wrote:

Hello Sara,

  but if we were moving from flex to re2c for that tokenizing scripts we'd
get a nice speed boost, too. Typically re2c based scanners are 2 to 3 times
faster than lex based ones. And oh-re2c allows unicode scanning (2 byte
input) and you can use the same .re to generate two .c files if necessary.

best regards
matcus

Thursday, March 9, 2006, 6:44:45 PM, you wrote:

>>> The inability to inject tokens and expressions into the lexer and
>>> parser is another limitation on what can be done from extensions in
>>> terms of syntax level features.  Yes, I know this is more of a problem
>>> with bison and flex than with the design of ZE, but that doesn't make
>>> it any less bothersome.
>>
>> Do other compiler tools allow this?
>>
> I've heard second hand that lemon does.  But I'm quite certain that
> rewriting the lexer/parser is not at the top of the list of 
productive ways

> to advance the language.

> -Sara




Best regards,
 Marcus

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


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

Re: [PHP-DEV] Give the Language a Rest motion

[Marcus Boerger]

Hello Zeev,

  yeah! which is why there is no need to do anything on that front :-)

marcus

Friday, March 10, 2006, 12:26:20 AM, you wrote:

> No speed boost with opcode caches, which will be bundled in PHP 6 :)

> Zeev

> At 01:15 10/03/2006, Marcus Boerger wrote:
>>Hello Sara,
>>
>>   but if we were moving from flex to re2c for that tokenizing scripts we'd
>>get a nice speed boost, too. Typically re2c based scanners are 2 to 3 times
>>faster than lex based ones. And oh-re2c allows unicode scanning (2 byte
>>input) and you can use the same .re to generate two .c files if necessary.
>>
>>best regards
>>matcus
>>
>>Thursday, March 9, 2006, 6:44:45 PM, you wrote:
>>
>> >>> The inability to inject tokens and expressions into the lexer and
>> >>> parser is another limitation on what can be done from extensions in
>> >>> terms of syntax level features.  Yes, I know this is more of a problem
>> >>> with bison and flex than with the design of ZE, but that doesn't make
>> >>> it any less bothersome.
>> >>
>> >> Do other compiler tools allow this?
>> >>
>> > I've heard second hand that lemon does.  But I'm quite certain that
>> > rewriting the lexer/parser is not at the top of the list of 
>> productive ways
>> > to advance the language.
>>
>> > -Sara
>>
>>
>>
>>
>>Best regards,
>>  Marcus
>>
>>--
>>PHP Internals - PHP Runtime Development Mailing List
>>To unsubscribe, visit: http://www.php.net/unsub.php




Best regards,
 Marcus

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

RE: [PHP-DEV] Give the Language a Rest motion

[Dmitry Stogov]

Just for info: GCC-4.1 now uses faster hand-written recursive-descent parser
(instead of bison generated).

Thanks. Dmitry.

> -Original Message-
> From: Zeev Suraski [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 10, 2006 2:26 AM
> To: Marcus Boerger
> Cc: Sara Golemon; internals@lists.php.net
> Subject: Re: [PHP-DEV] Give the Language a Rest motion
> 
> 
> No speed boost with opcode caches, which will be bundled in PHP 6 :)
> 
> Zeev
> 
> At 01:15 10/03/2006, Marcus Boerger wrote:
> >Hello Sara,
> >
> >   but if we were moving from flex to re2c for that 
> tokenizing scripts 
> >we'd get a nice speed boost, too. Typically re2c based 
> scanners are 2 
> >to 3 times faster than lex based ones. And oh-re2c allows unicode 
> >scanning (2 byte
> >input) and you can use the same .re to generate two .c files 
> if necessary.
> >
> >best regards
> >matcus
> >
> >Thursday, March 9, 2006, 6:44:45 PM, you wrote:
> >
> > >>> The inability to inject tokens and expressions into the 
> lexer and 
> > >>> parser is another limitation on what can be done from 
> extensions 
> > >>> in terms of syntax level features.  Yes, I know this is 
> more of a 
> > >>> problem with bison and flex than with the design of ZE, 
> but that 
> > >>> doesn't make it any less bothersome.
> > >>
> > >> Do other compiler tools allow this?
> > >>
> > > I've heard second hand that lemon does.  But I'm quite 
> certain that 
> > > rewriting the lexer/parser is not at the top of the list of
> > productive ways
> > > to advance the language.
> >
> > > -Sara
> >
> >
> >
> >
> >Best regards,
> >  Marcus
> >
> >--
> >PHP Internals - PHP Runtime Development Mailing List
> >To unsubscribe, visit: http://www.php.net/unsub.php
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 

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

RE: [PHP-DEV] Give the Language a Rest motion

[Scott A. Guyer]

FWIW, I support this motion.

I am never a fan of the software lifecycle that looks like
"here's a useful technology, now we just need this, 
and this...etc. ad nausea".  Why?

(1) Adds complexity
(2) You often get pulled out of your original design philosophy 
which puts the code's architectural integrity at risk.  Sometimes
this evolves into a proper code restructuring, but more often, it
does not.  Throughout history we have seen that things are the 
victim of their own success.  This end may well be inevitable, but
continually adding features and growing the system would only serve
to expedite that end.
(3) I favor small, simple, highly expressive languages that focus on
productivity in a stated problem domain.  Not large domain-independent
languages that do nothing exceptionally well.

I think the question needs to be asked repeatedly and often, "what
is our design philosophy for PHP, and is proposed feature X consistent
with that philosophy?"  If not, no feature X. 
(NOTE: it may be reasonable to separate PHP from Zend, or executor from
compiler, when asking this question.  Consider MSFT's CLR model,
for example.)


PHP = "PHP: Hypertext Preprocessor"  

I'll wager we have grown well beyond what that name suggests already.
And I'll ask the question, what the heck does jump have to do with that?
(not to insult any proponents, nor do I want to single that one out, 
it's just the one I know at the moment)

To be quite frank, I'm not sure object orientation has a place in
scripting.  Objects are great for organizing architectures (not necessary,
but useful).  But should we be concerned about organizing architectures in
script languages?  Aren't scripts supposed to be synonymous with "small set
of automation instructions" ?  Reasonable question.

Why is PHP still in play in the industry?  Because of it's perceived
productivity edge over Java (excluding ASP.NET at the moment since it's
single vendor status is the principal cause for it being ignored by
many companies).  If that perception is lost, it's over (developers who
are fans will still cling to it for some time, but the industry will 
move on).

Give the language a rest?...aye!  
Focus on automation and productivity?...aye!

Cheers,
-Scott

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pierre Joye]

I would also say it us time for us to get back in sync with the communities
needs. I am not talking about the last days RFCs but in general.
On Feb 20, 2013 7:19 PM, "Derick Rethans"  wrote:

> Looks like it is time to forward this email from 2006 again:
>
> -- Forwarded message --
> Date: Thu, 09 Mar 2006 12:57:32 +0200
> From: Zeev Suraski 
> To: internals@lists.php.net
> Subject: [PHP-DEV] Give the Language a Rest motion
>
> I'd like to raise a motion to 'Give the Language a Rest'.
>
> Almost a decade since we started with the 2nd iteration on the syntax (PHP
> 3),
> and 2 more major versions since then, and we're still heatedly debating on
> adding new syntactical, core level features.
>
> Is it really necessary?  I'd say in almost all cases the answer's no, and a
> bunch of cases where a new feature could be useful does not constitute a
> good
> enough reason to add a syntax level feature.  We might have to account for
> new
> technologies, or maybe new ways of thinking that might arise, but needless
> to
> say, most of the stuff we've been dealing with in recent times doesn't
> exactly
> fall in the category of cutting edge technology.
>
> My motion is to make it much, much more difficult to add new syntax-level
> features into PHP.  Consider only features which have significant traction
> to a
> large chunk of our userbase, and not something that could be useful in some
> extremely specialized edge cases, usually of PHP being used for non web
> stuff.
>
> How do we do it?  Unfortunately, I can't come up with a real mechanism to
> 'enforce' a due process and reasoning for new features.
>
> Instead, please take at least an hour to bounce this idea in the back of
> your
> mind, preferably more.  Make sure you think about the full context, the
> huge
> audience out there, the consequences of  making the learning curve steeper
> with
> every new feature, and the scope of the goodness that those new features
> bring.
> Consider how far we all come and how successful the PHP language is today,
> in
> implementing all sorts of applications most of us would have never even
> thought
> of when we created the language.
>
> Once you're done thinking, decide for yourself.  Does it make sense to be
> discussing new language level features every other week?  Or should we,
> perhaps,
> invest more in other fronts, which would be beneficial for a far bigger
> audience.  The levels above - extensions to keep with the latest
> technologies,
> foundation classes, etc.  Pretty much, the same direction other mature
> languages
> went to.
>
> To be clear, and to give this motion higher chances of success, I'm not
> talking
> about jump.  PHP can live with jump, almost as well as it could live
> without it
> :)  I'm talking about the general sentiment.
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Lars Strojny]

As a general reply: I’d like to disagree, and here is why. Yes, we should not 
let half baked features in but we need to add more and more features, also 
syntax wise. For three reasons:


 - Parity/expectations/me too: so you can do that in PHP as well
 - Expressiveness: allow better ways to express the same idea in more concise 
ways
 - Innovation: bring unexpected features to the language people didn’t even 
expect


Let’s recall a few of the latest additions:


 - 5.3: namespaces. Provided the foundation for awesome stuff like PSR-1, which 
in turn provides the foundation for the even more awesome stuff composer is.
 - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I am 
sure there is somebody out there :)
 - 5.3: Closures, huge thing for us, a matter of parity to other languages. 
Really changes the face of a lot of APIs (see e.g. Doctrine transactional(), 
the whole micro framework movement, React)
 - 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures are a 
little meh. But it was good we waited and got it right.
 - 5.4: Short array syntax. A parity/culture issue.
 - 5.4: Traits, I am happy we got horizontal reuse right
 - 5.4: array dereferencing. Very small but useful. To me it feels more like a 
bugfix
 - 5.4: callable type hint. Small change with a huge impact
 - 5.5: Generators, also a matter of parity and a matter of awesomeness
 - 5.5: ClassName::class syntax. A really good improvement to the overall 
usability of namespaces. Just imagine how much shorter unit test setUp() 
methods will become


What we have on our list that, from my perspective, will sooner or later hit us:


 - Property accessors in some form or another: a lot of people seem to like it.
 - Annotation support: we would have a lot of customers for it.
 - Autoboxing for primitives. Allows us to fix a lot of problems in 
ext/standard.
 - Unicode. Obviously.
 - Named parameters. A recurring topic might be a topic worth digging deeper.
 - I'm positive the Generics discussion will arise at some point again.


… and these are just the changes on a syntax/semantics level, I'm not talking 
about all the awesome technologies (one of which you are working on) we need to 
integrate tighter and eventually bundle with core. I don’t believe we should 
let our users outgrow the language, quite the opposite, we should grow with our 
users and the broader web community, otherwise we will fail. PHP is nowadays 
used for tasks it never was intended to be used but that’s a good thing. We 
need to continuously adapt. What’s true for software projects is true for 
languages: stop improving actually reduces its value over time.

cu,
Lars

Am 20.02.2013 um 19:18 schrieb Derick Rethans :

> Looks like it is time to forward this email from 2006 again:
> 
> -- Forwarded message --
> Date: Thu, 09 Mar 2006 12:57:32 +0200
> From: Zeev Suraski 
> To: internals@lists.php.net
> Subject: [PHP-DEV] Give the Language a Rest motion
> 
> I'd like to raise a motion to 'Give the Language a Rest'.
> 
> Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
> and 2 more major versions since then, and we're still heatedly debating on
> adding new syntactical, core level features.
> 
> Is it really necessary?  I'd say in almost all cases the answer's no, and a
> bunch of cases where a new feature could be useful does not constitute a good
> enough reason to add a syntax level feature.  We might have to account for new
> technologies, or maybe new ways of thinking that might arise, but needless to
> say, most of the stuff we've been dealing with in recent times doesn't exactly
> fall in the category of cutting edge technology.
> 
> My motion is to make it much, much more difficult to add new syntax-level
> features into PHP.  Consider only features which have significant traction to 
> a
> large chunk of our userbase, and not something that could be useful in some
> extremely specialized edge cases, usually of PHP being used for non web stuff.
> 
> How do we do it?  Unfortunately, I can't come up with a real mechanism to
> 'enforce' a due process and reasoning for new features.
> 
> Instead, please take at least an hour to bounce this idea in the back of your
> mind, preferably more.  Make sure you think about the full context, the huge
> audience out there, the consequences of  making the learning curve steeper 
> with
> every new feature, and the scope of the goodness that those new features 
> bring.
> Consider how far we all come and how successful the PHP language is today, in
> implementing all sorts of applications most of us would have never even 
> thought
> of when we created the language.
> 
> Once you're done thinking, decide for yourself.  Does it make sense to be
> discussing new language level features every other week?  Or should we, 
> perhaps,
> invest more in other fronts, which would be beneficial for a far bigger
> audience.  The levels above - extensions to keep with

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Levi Morrison]

>  - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I 
> am sure there is somebody out there :)

An associate of mine used it in his HTTP message parser. He's sure
glad it's there :)

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Ryan McCue]

Levi Morrison wrote:
>>  - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I 
>> am sure there is somebody out there :)
> 
> An associate of mine used it in his HTTP message parser. He's sure
> glad it's there :)
> 

Conversely, I have two HTTP message parsers that I maintain, and neither
of them use goto. Certainly possible to avoid it there.

That said, I do think goto has legitimate uses, even if I don't need it.

-- 
Ryan McCue


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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Eloy Bote Falcon]

2013/2/20 Derick Rethans :
> Looks like it is time to forward this email from 2006 again:
>
> -- Forwarded message --
> Date: Thu, 09 Mar 2006 12:57:32 +0200
> From: Zeev Suraski 
> To: internals@lists.php.net
> Subject: [PHP-DEV] Give the Language a Rest motion
>
> I'd like to raise a motion to 'Give the Language a Rest'.
>
> Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
> and 2 more major versions since then, and we're still heatedly debating on
> adding new syntactical, core level features.
>
> Is it really necessary?  I'd say in almost all cases the answer's no, and a
> bunch of cases where a new feature could be useful does not constitute a good
> enough reason to add a syntax level feature.  We might have to account for new
> technologies, or maybe new ways of thinking that might arise, but needless to
> say, most of the stuff we've been dealing with in recent times doesn't exactly
> fall in the category of cutting edge technology.
>
> My motion is to make it much, much more difficult to add new syntax-level
> features into PHP.  Consider only features which have significant traction to 
> a
> large chunk of our userbase, and not something that could be useful in some
> extremely specialized edge cases, usually of PHP being used for non web stuff.
>
> How do we do it?  Unfortunately, I can't come up with a real mechanism to
> 'enforce' a due process and reasoning for new features.
>
> Instead, please take at least an hour to bounce this idea in the back of your
> mind, preferably more.  Make sure you think about the full context, the huge
> audience out there, the consequences of  making the learning curve steeper 
> with
> every new feature, and the scope of the goodness that those new features 
> bring.
> Consider how far we all come and how successful the PHP language is today, in
> implementing all sorts of applications most of us would have never even 
> thought
> of when we created the language.
>
> Once you're done thinking, decide for yourself.  Does it make sense to be
> discussing new language level features every other week?  Or should we, 
> perhaps,
> invest more in other fronts, which would be beneficial for a far bigger
> audience.  The levels above - extensions to keep with the latest technologies,
> foundation classes, etc.  Pretty much, the same direction other mature 
> languages
> went to.
>
> To be clear, and to give this motion higher chances of success, I'm not 
> talking
> about jump.  PHP can live with jump, almost as well as it could live without 
> it
> :)  I'm talking about the general sentiment.
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Agree. There are only a few core devs working daily in the PHP
internals. I would say please give the Language (and devs) a rest
motion, because there are a lot of bugs and work to be done but I'm
afraid that is more easy/funny to request a new feature/syntax than do
the grunt work :(

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pierre Joye]

hi,

On Thu, Feb 21, 2013 at 10:45 AM, Eloy Bote Falcon  wrote:

> Agree. There are only a few core devs working daily in the PHP
> internals. I would say please give the Language (and devs) a rest
> motion, because there are a lot of bugs and work to be done but I'm
> afraid that is more easy/funny to request a new feature/syntax than do
> the grunt work :(

And those proposing new long awaited features are new contributors and
those actually doing the household job too, since quite some time. So
basically your last argument is contradicted by the reality.

Cheers,
-- 
Pierre

@pierrejoye

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

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Zeev Suraski]

What you're bringing up is not at all about adapting.  Adapting is
something we do at the extensions, frameworks and tools levels.  I'm happy
to say PHP's ecosystem here is very healthy, in my opinion.

Adapting is not what we're dealing with here.  We're talking about Adding.

By adding more and more, we're making the language more and more complex,
less and less accessible to both new and existing developers, thereby
hurting its #1 appeal - simplicity.  As we thrust forward towards 5.5,
more than half of the community is still on 5.2.  5.4 is virtually
nonexistent in terms of real world usage, and yet we thrust forward to
5.5, as if the community at large cares about all these new features.  The
community is voting with its feet, and that is probably the best survey
we're ever going to get.

I'm not saying we shouldn't add new features.  But I am saying that we
shouldn't add many of them.  The very few we should add - should have
exceptional 'return on investment'.  To be clear, the investment isn't
just the effort to develop or even maintain the implementation - that's
not even the main point.  It's the increased complexity that each and
every new language construct brings with it, whether we like it or not.

There used to be a language that was the Queen of the Web.  It was full of
clever syntax.  It prided itself on having a variety of expressive ways of
doing the same thing.  You're on the mailing list of the language that
dethroned it.

Zeev


> -Original Message-
> From: Lars Strojny [mailto:l...@strojny.net]
> Sent: Thursday, February 21, 2013 1:15 AM
> To: Derick Rethans; PHP Developers Mailing List
> Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
>
> As a general reply: I'd like to disagree, and here is why. Yes, we
should not let
> half baked features in but we need to add more and more features, also
syntax
> wise. For three reasons:
>
>
>  - Parity/expectations/me too: so you can do that in PHP as well
>  - Expressiveness: allow better ways to express the same idea in more
concise
> ways
>  - Innovation: bring unexpected features to the language people didn't
even
> expect
>
>
> Let's recall a few of the latest additions:
>
>
>  - 5.3: namespaces. Provided the foundation for awesome stuff like
PSR-1,
> which in turn provides the foundation for the even more awesome stuff
> composer is.
>  - 5.3: goto. A good thing we can do it. I'm not sure for what exactly
but I am
> sure there is somebody out there :)
>  - 5.3: Closures, huge thing for us, a matter of parity to other
languages. Really
> changes the face of a lot of APIs (see e.g. Doctrine transactional(),
the whole
> micro framework movement, React)
>  - 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures
are a little
> meh. But it was good we waited and got it right.
>  - 5.4: Short array syntax. A parity/culture issue.
>  - 5.4: Traits, I am happy we got horizontal reuse right
>  - 5.4: array dereferencing. Very small but useful. To me it feels more
like a
> bugfix
>  - 5.4: callable type hint. Small change with a huge impact
>  - 5.5: Generators, also a matter of parity and a matter of awesomeness
>  - 5.5: ClassName::class syntax. A really good improvement to the
overall
> usability of namespaces. Just imagine how much shorter unit test setUp()
> methods will become
>
>
> What we have on our list that, from my perspective, will sooner or later
hit us:
>
>
>  - Property accessors in some form or another: a lot of people seem to
like it.
>  - Annotation support: we would have a lot of customers for it.
>  - Autoboxing for primitives. Allows us to fix a lot of problems in
ext/standard.
>  - Unicode. Obviously.
>  - Named parameters. A recurring topic might be a topic worth digging
deeper.
>  - I'm positive the Generics discussion will arise at some point again.
>
>
> . and these are just the changes on a syntax/semantics level, I'm not
talking
> about all the awesome technologies (one of which you are working on) we
need
> to integrate tighter and eventually bundle with core. I don't believe we
should
> let our users outgrow the language, quite the opposite, we should grow
with
> our users and the broader web community, otherwise we will fail. PHP is
> nowadays used for tasks it never was intended to be used but that's a
good
> thing. We need to continuously adapt. What's true for software projects
is true
> for languages: stop improving actually reduces its value over time.
>
> cu,
> Lars
>
> Am 20.02.2013 um 19:18 schrieb Derick Rethans :
>
> > Looks like it is time to forward this email from 2006 again:
> >
> > -- Forwarded message --
> &g

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pierre Joye]

hi Zeev,

On Thu, Feb 21, 2013 at 10:56 AM, Zeev Suraski  wrote:
> What you're bringing up is not at all about adapting.  Adapting is
> something we do at the extensions, frameworks and tools levels.  I'm happy
> to say PHP's ecosystem here is very healthy, in my opinion.

Yes, most of the time. But the language needs evolution, must have evolution.

F.e., how long have we been battled for annotations? With all
respects, it is about being blind and stubborn to say that PHP should
not have annotations. But due to some "I'm happy with what we have
now" way of doing things, we are very unlikely to have them any time
soon, even if any major projects out there are waiting for it, for
years. Even the ZendFramework leads want them now (changed their mind
since the last attempt).

This is not about borking the language with useless features. This is
not about being on the cutting edge. this is about catching up with
the competition.

> Adapting is not what we're dealing with here.  We're talking about Adding.

Adding? Surely a matter of wording. I'd to say evolve and catch up.

> By adding more and more, we're making the language more and more complex,
> less and less accessible to both new and existing developers, thereby
> hurting its #1 appeal - simplicity.

I heard that in php 4 > 5 and OO, and all we rejected back then have
been introduced since then. Not sure what is the best way, trying to
stop with all four feet (to take your analogy) any kind of
additions/evolution/catching up and then still doing it but years
later, or trying to get a bit more open minded and listen to our
communities.

> As we thrust forward towards 5.5,
> more than half of the community is still on 5.2.  5.4 is virtually
> nonexistent in terms of real world usage, and yet we thrust forward to
> 5.5, as if the community at large cares about all these new features.  The
> community is voting with its feet, and that is probably the best survey
> we're ever going to get.

Excuse me? Voting with its feet? Dare to explain the underlying
meaning of this comment?


> I'm not saying we shouldn't add new features.  But I am saying that we
> shouldn't add many of them.  The very few we should add - should have
> exceptional 'return on investment'.  To be clear, the investment isn't
> just the effort to develop or even maintain the implementation - that's
> not even the main point.  It's the increased complexity that each and
> every new language construct brings with it, whether we like it or not.

Yes, totally agree here. Annotation and usable getter/setter syntax
have a huge ROI. Discuss with any application or framework
developers/users will bring you to the same conclusion.

> There used to be a language that was the Queen of the Web.  It was full of
> clever syntax.  It prided itself on having a variety of expressive ways of
> doing the same thing.  You're on the mailing list of the language that
> dethroned it.

You are living in the past glory. We are not willing to make PHP more
complex or kill it. We are willing to make compromises between the
2000s simplicity and the needs of modern application developments.
These compromises are not only required but possible.


Cheers,
--
Pierre

@pierrejoye

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Lester Caine]

Zeev Suraski wrote:

There used to be a language that was the Queen of the Web.  It was full of
clever syntax.  It prided itself on having a variety of expressive ways of
doing the same thing.  You're on the mailing list of the language that
dethroned it.
And the majority of END USERS are more than happy with the websites it is 
serving up today! If you want to evolve the language then much more effort 
should be put into providing tools that update the current user base rather than 
simply throwing in switches which hide all the problems :( Having to manually 
update sites on a case by case basis is what is currently holding things back - 
and stopping ISP's switching to the 'latest and greatest'!


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Zeev Suraski]

Pierre,

People who think differently from you are not necessarily blind of
stubborn.  I honestly think that those comments were completely out of
line in several different ways.

Regarding 'voting with feet', it's an idiom, look it up.

Zeev


> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Thursday, February 21, 2013 12:09 PM
> To: Zeev Suraski
> Cc: Lars Strojny; Derick Rethans; PHP Developers Mailing List
> Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
>
> hi Zeev,
>
> On Thu, Feb 21, 2013 at 10:56 AM, Zeev Suraski  wrote:
> > What you're bringing up is not at all about adapting.  Adapting is
> > something we do at the extensions, frameworks and tools levels.  I'm
> > happy to say PHP's ecosystem here is very healthy, in my opinion.
>
> Yes, most of the time. But the language needs evolution, must have
evolution.
>
> F.e., how long have we been battled for annotations? With all respects,
it is
> about being blind and stubborn to say that PHP should not have
annotations.
> But due to some "I'm happy with what we have now" way of doing things,
we
> are very unlikely to have them any time soon, even if any major projects
out
> there are waiting for it, for years. Even the ZendFramework leads want
them
> now (changed their mind since the last attempt).
>
> This is not about borking the language with useless features. This is
not about
> being on the cutting edge. this is about catching up with the
competition.
>
> > Adapting is not what we're dealing with here.  We're talking about
Adding.
>
> Adding? Surely a matter of wording. I'd to say evolve and catch up.
>
> > By adding more and more, we're making the language more and more
> > complex, less and less accessible to both new and existing developers,
> > thereby hurting its #1 appeal - simplicity.
>
> I heard that in php 4 > 5 and OO, and all we rejected back then have
been
> introduced since then. Not sure what is the best way, trying to stop
with all four
> feet (to take your analogy) any kind of additions/evolution/catching up
and then
> still doing it but years later, or trying to get a bit more open minded
and listen to
> our communities.
>
> > As we thrust forward towards 5.5,
> > more than half of the community is still on 5.2.  5.4 is virtually
> > nonexistent in terms of real world usage, and yet we thrust forward to
> > 5.5, as if the community at large cares about all these new features.
> > The community is voting with its feet, and that is probably the best
> > survey we're ever going to get.
>
> Excuse me? Voting with its feet? Dare to explain the underlying meaning
of this
> comment?
>
>
> > I'm not saying we shouldn't add new features.  But I am saying that we
> > shouldn't add many of them.  The very few we should add - should have
> > exceptional 'return on investment'.  To be clear, the investment isn't
> > just the effort to develop or even maintain the implementation -
> > that's not even the main point.  It's the increased complexity that
> > each and every new language construct brings with it, whether we like
it or
> not.
>
> Yes, totally agree here. Annotation and usable getter/setter syntax have
a huge
> ROI. Discuss with any application or framework developers/users will
bring you
> to the same conclusion.
>
> > There used to be a language that was the Queen of the Web.  It was
> > full of clever syntax.  It prided itself on having a variety of
> > expressive ways of doing the same thing.  You're on the mailing list
> > of the language that dethroned it.
>
> You are living in the past glory. We are not willing to make PHP more
complex or
> kill it. We are willing to make compromises between the 2000s simplicity
and the
> needs of modern application developments.
> These compromises are not only required but possible.
>
>
> Cheers,
> --
> Pierre
>
> @pierrejoye

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Terry Ellison]

Here is a counterpoint to that expressed by Lars.  Many if not most 
shared hosting providers don't offer PHP 5.4 yet.  Ditto many 
enterprises have yet to adopt it.  The main reason?  I think its that 
old Backwards Compatibility issue that has been discussed heavily on 
this DL.


When major apps like mediaWiki break with a new release of PHP (see 
http://www.mediawiki.org/wiki/Compatibility, and this is quite typical), 
upgrading PHP versions represents a major headache for both hosting 
providers and larger enterprises that want  to maintain standard 
infrastructure build templates, as each none-BC PHP upgrade represents a 
major cost in either loss of customer satisfaction or IT investment for 
little or no tangible business benefit.


New features are often nice for the app developer, so the result is that 
they then get used by apps development teams, and the provider or 
infrastructure team then has to manage the ripple effects on a complex 
infrastructure permitted configuration matrix across hundreds or 
thousands of apps.


I am not saying that the PHP dev team should freeze PHP, but what I am 
suggesting is that the PHP team should also consider the compatibility 
impacts across versions so that enterprises and hosting providers who 
have adopted PHP can control their through-life maintenance costs.


There are things that the PHP team could do to help mitigate this issue 
-- for example producing standard templates so that, say PHP 5.3, 5.4 
and 5.5 based apps can coexist and perform (e.g. with APC or O+) on the 
*same* Apache2 (or nginx, ...) stack.


Change is good, but too much change too fast without regard to the cost 
consequence will ultimately alienate the CIOs and CTOs who set platform 
policies.



On 20/02/13 23:15, Lars Strojny wrote:

As a general reply: I’d like to disagree, and here is why. Yes, we should not 
let half baked features in but we need to add more and more features, also 
syntax wise. For three reasons:


  - Parity/expectations/me too: so you can do that in PHP as well
  - Expressiveness: allow better ways to express the same idea in more concise 
ways
  - Innovation: bring unexpected features to the language people didn’t even 
expect


Let’s recall a few of the latest additions:


  - 5.3: namespaces. Provided the foundation for awesome stuff like PSR-1, 
which in turn provides the foundation for the even more awesome stuff composer 
is.
  - 5.3: goto. A good thing we can do it. I'm not sure for what exactly but I 
am sure there is somebody out there :)
  - 5.3: Closures, huge thing for us, a matter of parity to other languages. 
Really changes the face of a lot of APIs (see e.g. Doctrine transactional(), 
the whole micro framework movement, React)
  - 5.4: Closures 2.0 with $this binding. Honestly, without it, Closures are a 
little meh. But it was good we waited and got it right.
  - 5.4: Short array syntax. A parity/culture issue.
  - 5.4: Traits, I am happy we got horizontal reuse right
  - 5.4: array dereferencing. Very small but useful. To me it feels more like a 
bugfix
  - 5.4: callable type hint. Small change with a huge impact
  - 5.5: Generators, also a matter of parity and a matter of awesomeness
  - 5.5: ClassName::class syntax. A really good improvement to the overall 
usability of namespaces. Just imagine how much shorter unit test setUp() 
methods will become


What we have on our list that, from my perspective, will sooner or later hit us:


  - Property accessors in some form or another: a lot of people seem to like it.
  - Annotation support: we would have a lot of customers for it.
  - Autoboxing for primitives. Allows us to fix a lot of problems in 
ext/standard.
  - Unicode. Obviously.
  - Named parameters. A recurring topic might be a topic worth digging deeper.
  - I'm positive the Generics discussion will arise at some point again.


… and these are just the changes on a syntax/semantics level, I'm not talking 
about all the awesome technologies (one of which you are working on) we need to 
integrate tighter and eventually bundle with core. I don’t believe we should 
let our users outgrow the language, quite the opposite, we should grow with our 
users and the broader web community, otherwise we will fail. PHP is nowadays 
used for tasks it never was intended to be used but that’s a good thing. We 
need to continuously adapt. What’s true for software projects is true for 
languages: stop improving actually reduces its value over time.

cu,
Lars

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Nikita Popov]

On Wed, Feb 20, 2013 at 7:18 PM, Derick Rethans  wrote:

> Once you're done thinking, decide for yourself.  Does it make sense to be
> discussing new language level features every other week?  Or should we,
> perhaps,
> invest more in other fronts, which would be beneficial for a far bigger
> audience.  The levels above - extensions to keep with the latest
> technologies,
> foundation classes, etc.  Pretty much, the same direction other mature
> languages
> went to.
>

Won't comment one the rest of this (to avoid more flame), but wanted to say
something about this: If you want more foundation classes / libraries, then
what PHP has to do is move more of it's standard library to PHP. C has a
large implementational overhead and an even larger entry barrier. To make
major advances on the library front, it needs to move to PHP. There are
some tough problems associated with this, but I think they can be solved
and PHP would benefit a lot from this.

Nikita

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pierre Joye]

Zeev,

On Thu, Feb 21, 2013 at 12:24 PM, Zeev Suraski  wrote:
> Pierre,
>
> People who think differently from you are not necessarily blind of
> stubborn.  I honestly think that those comments were completely out of
> line in several different ways.

It is not my opinion but a simple fact. Yes, you can disagree with an
idea or proposal, but the cost of such disagree, despite huge
community support, is too high and it is more than counter productive.
Hence this comment.

> Regarding 'voting with feet', it's an idiom, look it up.

I know, still do not think it fits as comment either here.

-- 
Pierre

@pierrejoye

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Lester Caine]

Pierre Joye wrote:

>Regarding 'voting with feet', it's an idiom, look it up.

I know, still do not think it fits as comment either here.


I read this as simply "People are not leaving PHP in droves simply because it 
does not have xxx" - actually the opposite, but that growth in use is not into 
PHP5.4 ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Florin Razvan Patan]

Hello,


This might sound as a rant but I assure you it's not.
It's just how I see the things from my perspective and that of
my colleagues/employer.

On Thu, Feb 21, 2013 at 11:56 AM, Zeev Suraski  wrote:
> What you're bringing up is not at all about adapting.  Adapting is
> something we do at the extensions, frameworks and tools levels.  I'm happy
> to say PHP's ecosystem here is very healthy, in my opinion.

Could you please share how you measure that the ecosystem is healthy or
not? And What do you mean in terms it's healthy? Is it adoption rate of new
versions, penetration degree, influx of new people?

>
> Adapting is not what we're dealing with here.  We're talking about Adding.

I think that there are are cases where Adding is a mean for adapting. Like
for example, the desire to have built-in annotation support.

>
> By adding more and more, we're making the language more and more complex,
> less and less accessible to both new and existing developers, thereby
> hurting its #1 appeal - simplicity.  As we thrust forward towards 5.5,
> more than half of the community is still on 5.2.  5.4 is virtually
> nonexistent in terms of real world usage, and yet we thrust forward to
> 5.5, as if the community at large cares about all these new features.  The
> community is voting with its feet, and that is probably the best survey
> we're ever going to get.

The adoption of PHP 5.4 has been next to 0 because of the various BC breaks
done, and even more, because APC has had a stable version only after about
one year. Enterprise users such as myself can't just go to work and say: Hey,
there's a new PHP version, it breaks some things for which we'll need time to
fix, it adds features that we could really use but we can live without them and
do workarounds like until now. Even if we'd had time to fix the broken things
there's a tiny issue, we can't be sure of how APC will work and if it's going to
crash our business or not.

Enterprise users want stability above all else, even if it means that their devs
will need to live without new features for a long time and work more in order
to develop their software.

Things that happened in PHP 5.4 should never happen again if you want to
have larger adoption rates. ISPs can't just upgrade their software stack
knowing that 99% of the sites they hold are at risk of not working due to
BC breaks between 5.X releases. Deprecating is one thing, removing is
another thing.


>
> I'm not saying we shouldn't add new features.  But I am saying that we
> shouldn't add many of them.  The very few we should add - should have
> exceptional 'return on investment'.  To be clear, the investment isn't
> just the effort to develop or even maintain the implementation - that's
> not even the main point.  It's the increased complexity that each and
> every new language construct brings with it, whether we like it or not.

I totally agree with you on this one. Maybe extensions bundled with
default distribution could be a good solution for adding new things that
could be disabled on demand via configuration options.

>
> There used to be a language that was the Queen of the Web.  It was full of
> clever syntax.  It prided itself on having a variety of expressive ways of
> doing the same thing.  You're on the mailing list of the language that
> dethroned it.
>
> Zeev
>

Currently in PHP you can do the same thing about the same way.
The difference is that right now, there's a bunch of things missing
when compared to other languages and this is a push off.

Consider the following scenario: We are a team of 60 programmers
all with various PHP skills. We'll need say threading to better handle
some reporting application. We all know PHP and maybe 2 of us
know Erlang. Say we care about those who'll need to maintain the
application when we'll be out of office or at other companies. The
choice in this case is obvious for us. Use PHP. We simply can't
afford to have new people hired that are specialized in a language
that best fits our needs nor our colleagues might have time to learn
how to fix something in a critical system when we are not around.
Erlang should be the obvious choice in case of high concurrency
and threading but we can't just use another language.

Or have a look at annotations. Zend Framework 2 uses them (hint),
Symfony2 uses them, Doctrine uses them and so on. All major
players in the PHP world. It's frameworks and tools that also
drive the adoption of a language not just the features. Imho, if most
major players say they need something in order to build better
tools for their users then I guess they should be heard of by the
developers. Just like what happens when a end user of a framework
wants a new feature in the framework they use.

The problem with PHP is that it's written in C and even if it grew so
big in the past years, the users to contributors conversion is very
low. But then again, look at the website. There's nothing saying on
it about contributions. There are no Bug hunt da

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Zeev Suraski]

> > People who think differently from you are not necessarily blind of
> > stubborn.  I honestly think that those comments were completely out of
> > line in several different ways.
>
> It is not my opinion but a simple fact.

That comment would have been funny if it wasn't sad.  I'll leave it at
that.

> > Regarding 'voting with feet', it's an idiom, look it up.
>
> I know, still do not think it fits as comment either here.

Of course it does.

Zeev

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

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Zeev Suraski]

> -Original Message-
> From: Florin Razvan Patan [mailto:florinpa...@gmail.com]
> Sent: Thursday, February 21, 2013 3:15 PM
> To: Zeev Suraski
> Cc: Lars Strojny; Derick Rethans; PHP Developers Mailing List
> Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
>
> On Thu, Feb 21, 2013 at 11:56 AM, Zeev Suraski  wrote:
> > What you're bringing up is not at all about adapting.  Adapting is
> > something we do at the extensions, frameworks and tools levels.  I'm
> > happy to say PHP's ecosystem here is very healthy, in my opinion.
>
> Could you please share how you measure that the ecosystem is healthy or
> not?
> And What do you mean in terms it's healthy? Is it adoption rate of new
> versions,
> penetration degree, influx of new people?

We have a good solid set of extensions, including lots of activity on PECL.
We have flourishing framework ecosystems that are extremely active.  We have
excellent support from tools, both free and commercial.  That's how I
measure it.


> > Adapting is not what we're dealing with here.  We're talking about
> > Adding.
>
> I think that there are are cases where Adding is a mean for adapting. Like
> for
> example, the desire to have built-in annotation support.

That's not adaptation in my book.  That's addition.  It's not the technology
landscape that changed that now you need annotations;  It's that some people
consider this feature cool and useful, and want to import it into PHP
although it does not in fact enable you to do anything you can't do today,
while it does add a lot of complexity to the language.

> > By adding more and more, we're making the language more and more
> > complex, less and less accessible to both new and existing developers,
> > thereby hurting its #1 appeal - simplicity.  As we thrust forward
> > towards 5.5, more than half of the community is still on 5.2.  5.4 is
> > virtually nonexistent in terms of real world usage, and yet we thrust
> > forward to 5.5, as if the community at large cares about all these new
> > features.  The community is voting with its feet, and that is probably
> > the best survey we're ever going to get.
>
> The adoption of PHP 5.4 has been next to 0 because of the various BC
> breaks
> done, and even more, because APC has had a stable version only after about
> one year. Enterprise users such as myself can't just go to work and say:
> Hey,
> there's a new PHP version, it breaks some things for which we'll need time
> to fix,
> it adds features that we could really use but we can live without them and
> do
> workarounds like until now. Even if we'd had time to fix the broken things
> there's a tiny issue, we can't be sure of how APC will work and if it's
> going to
> crash our business or not.

PHP 5.4 actually brings very little BC breakage.

Most companies as well as private users I know haven't even gotten to
evaluate PHP 5.4 and even learn that APC doesn't work on it, because
honestly, they couldn't care less.  For them, 5.3 or even 5.2 are good
enough, they don't even inquire into 5.4.
For the vast majority of companies/users, the motivation to upgrade PHP
would be coming from two places:
1. If they need it in order to run their apps (5.3 is required by a growing
number of frameworks (ZF2, Sf2)).
2. If they're worried about security updates after the EOL.

The point is that "the sky is falling" mentality that was expressed here by
certain people could not be farther from reality.  If we take a look at the
userbase at large, people are content with PHP's syntax, and the constant
drive for additions to it simply makes no sense.

> Enterprise users want stability above all else, even if it means that
> their devs will
> need to live without new features for a long time and work more in order
> to
> develop their software.

It's not just enterprises, effectively it's anybody who uses PHP for
anything that’s' beyond a hobby.

> > I'm not saying we shouldn't add new features.  But I am saying that we
> > shouldn't add many of them.  The very few we should add - should have
> > exceptional 'return on investment'.  To be clear, the investment isn't
> > just the effort to develop or even maintain the implementation -
> > that's not even the main point.  It's the increased complexity that
> > each and every new language construct brings with it, whether we like it
> > or
> not.
>
> I totally agree with you on this one. Maybe extensions bundled with
> default
> distribution could be a good solution for adding new things that could be
> disabled on demand via configu

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pierre Joye]

hi,

On Thu, Feb 21, 2013 at 2:59 PM, Zeev Suraski  wrote:

> That's not adaptation in my book.  That's addition.  It's not the technology
> landscape that changed that now you need annotations;  It's that some people
> consider this feature cool and useful, and want to import it into PHP
> although it does not in fact enable you to do anything you can't do today,
> while it does add a lot of complexity to the language.

I can do everything PHP does in assembler, but I do not implement web
apps in assembler.


Cheers,
-- 
Pierre

@pierrejoye

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

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Zeev Suraski]

> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Thursday, February 21, 2013 4:08 PM
> To: Zeev Suraski
> Cc: Florin Razvan Patan; Lars Strojny; Derick Rethans; PHP Developers
Mailing
> List
> Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
>
> hi,
>
> On Thu, Feb 21, 2013 at 2:59 PM, Zeev Suraski  wrote:
>
> > That's not adaptation in my book.  That's addition.  It's not the
> > technology landscape that changed that now you need annotations;  It's
> > that some people consider this feature cool and useful, and want to
> > import it into PHP although it does not in fact enable you to do
> > anything you can't do today, while it does add a lot of complexity to
the
> language.
>
> I can do everything PHP does in assembler, but I do not implement web
apps in
> assembler.

Actually no, you can't.  You won't live long enough to write a meaningful
web app in asm, even if you live to be exceptionally old, and I certainly
wish you well.

Zeev

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Michael Shadle]

On Feb 21, 2013, at 1:56 AM, Zeev Suraski  wrote:

> There used to be a language that was the Queen of the Web.  It was full of
> clever syntax.  It prided itself on having a variety of expressive ways of
> doing the same thing.  You're on the mailing list of the language that
> dethroned it.

This needs to be printed and framed somewhere.

Your comments are great, but this last paragraph is magnificent.

+1

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Rasmus Lerdorf]

In the slice of the "community" where I spend most of my time,
medium-to-large companies using PHP with their own custom code on
hundreds to thousands or even 10's of thousands of servers, neither
annotations nor getter/setter are anywhere on their wishlist radar. What
they most desire is performance, robustness and security. They would
love to see a PHP release that had no syntax changes, no BC changes, but
was twice as fast and crashed half as much. I realize this is just one
(small?) slice of the community but so is the part of the community
wanting annotations. This is the balancing act we have to perform. It is
not stubbornness, nor living in the past, it is recognizing that each
and every major feature addition has a destabilizing effect on the
codebase and if the addition only serves a small slice of the userbase
we have to think long and hard about the merits of it.

Personally I would love to see more RFCs focusing on performance and
less on syntax changes. Of course, a syntax change RFC, and even the
initial (often shaky) implementation of a syntax-related change is much
much easier to whip up than the deep analysis, profiling and creativity
required to find and come up with ways to make a complex piece of code
faster or use less memory.

-Rasmus

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Arvids Godjuks]

Hello, didn't read the whole thread, just a few messages at the start. But
because I'm replying to the starting message, it's not relevant :)

In principle, as a user-land developer, I agree with the motion. It's too
much fancy new shiny stuff lately and no actual improvement on the old
stuff that really needs fixing or updating/rewriting (PDO anyone? Years
behind every db driver extension there is in PHP, and as far as I'm
concerned - it should be dropped and concentrate on standardize the db
extension public API).
As far as I see, there is technical debt piling up and except the actual
core developers no one understands that - people just spawn RFC's like
crazy. As it was said countless times - PHP core team lacks resources to
fix many issues that are already there and new stuff just makes it worse.


Actually, if I was a core team member (sadly C is not my love and most of
the stuff I want to change requires actual coding), I would push a motion
to temporary suspend accepting RFC's that introduce new features and devote
release after 5.5 to fixing and rewriting the old stuff and bug fixing. And
that can prove to be a much more positive that just new features. I think
with last two releases there was ton of stuff added and it will take time
to actually grasp it and start using it. Hell, I like traits, but I can't
put a finger on how to use them at the moment. And it will take me some
considerable time to actually find a place for them and integrate them into
my work so that they fit just right. Late static binding? Hell, still
didn't use it at all. Anonymous functions - yeah, this one is all over my
code now (of course not just for the sake of it) and some other recent
stuff I use too.
Ok, I have to stop mumbling. What I wanted to say - it will take time for
developers, community, frameworks and hosting companies to catch up with
the stuff that was introduced in 5.3, 5.4 and will be in 5.5. To my opinion
there should be a pause in new additions and time taken to take care of the
old stuff that needs love, some need it desperately.

Thanks,
Arvids.

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Marco Pivetta]

On 21 February 2013 16:30, Rasmus Lerdorf  wrote:

> In the slice of the "community" where I spend most of my time
>

No hard feelings, but it would be awesome if that part of the "community"
(the one that basically avoids social coding as far as I can see, not to be
taken as a sin, but still "meh") didn't just try to hold back PHP because
of business decisions based on obsolescence.
If there is some momentum to get change, I see these big brakes set by
people who don't even express their opinion nor get interested in newly
developed packages over here.
It would already be nice to have them provide their opinion, assuming it
goes a bit deeper than "YAGNI".

No BC changes is basically impossible if you want to get better software:
improvement comes always with changes.

I can absolutely understand that the core team does not have enough human
resources to think about new functionality, and probably not even
maintenance (I even feel like a stranger forcing his own ideas in here,
since I also have no C-fu), but why would this stop things from being
suggested?
If you don't have time for a feature, then that's perfectly ok: just vote
"NO".

Don't sell us the "YAGNI" or "additional complexity" story: annotations and
property accessors already demonstrated that there are use cases that even
bring performance improvements.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Johannes Schlüter]

On Thu, 2013-02-21 at 16:54 +0100, Marco Pivetta wrote:
> No hard feelings, but it would be awesome if that part of the "community"
> (the one that basically avoids social coding as far as I can see, not to be
> taken as a sin, but still "meh") didn't just try to hold back PHP because
> of business decisions based on obsolescence.

The quoted business decision was "We want something stable and fast", an
emphasis of fixing bugs over adding new ones. This sounds sane to me.

johannes



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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Marco Pivetta]

On 21 February 2013 17:04, Johannes Schlüter  wrote:

> The quoted business decision was "We want something stable and fast", an
> emphasis of fixing bugs over adding new ones. This sounds sane to me.
>
> johannes
>
>
>
Doesn't exclude new features then: so what is this all about?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Levi Morrison]

> Personally I would love to see more RFCs focusing on performance and
> less on syntax changes.

Some recent tests I performed indicate that JavaScript and Dart are
both significantly faster than PHP when working with just arrays and
numbers. If anyone is interested I can provide the test code for more
scrutiny.  I'd like to see more performance enhancements but I am not
against other enhancements as well.

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Florin Razvan Patan]

Hello,


On Thu, Feb 21, 2013 at 5:30 PM, Rasmus Lerdorf  wrote:
> In the slice of the "community" where I spend most of my time,
> medium-to-large companies using PHP with their own custom code on
> hundreds to thousands or even 10's of thousands of servers, neither
> annotations nor getter/setter are anywhere on their wishlist radar. What
> they most desire is performance, robustness and security. They would
> love to see a PHP release that had no syntax changes, no BC changes, but
> was twice as fast and crashed half as much. I realize this is just one
> (small?) slice of the community but so is the part of the community
> wanting annotations. This is the balancing act we have to perform. It is
> not stubbornness, nor living in the past, it is recognizing that each
> and every major feature addition has a destabilizing effect on the
> codebase and if the addition only serves a small slice of the userbase
> we have to think long and hard about the merits of it.

I couldn't agree with you more. While the company that I'm working on
just hit the hundred limit, this is one of our concerns as well.

And like I've said, stability is a key factor for us. Speed is also critical
and I agree that everyone needs more speed any time you ask them.

The examples I gave where just examples, not something that I'm crying
that is not added to the language but my company is also trying to be
open to any new things that would make our lives easier and help us
code faster, easier, better and so on.

I think it would be helpful to have something like a roadmap with various
features and changes both in regards to language and features as well
as performance.

Also, having a clear line of when features will be deprecated then removed
will go a long way to help out users while writing their software. That way,
people would know what to expect from the language and when it would
be the time to upgrade.

You could use the example of JetBrains and how they manage their
products via their issue tracker, http://youtrack.jetbrains.com/issues/WI
in which everyone that is not part of the core team can 'vote' for a feature
or bug or what not and participate in a threaded discussion in a simpler
manner.

This would bring you a nicer interface that the current ones while being
able to also gauge the community interest in certain issues.

I think if the PHP group would ask JetBrains for their software for free,
they wouldn't say no and I gave them as an example because I'm using
their beta software since it the second is out on their download servers
and I'm reporting every crash that I can as they made it really easy for
me to help them out.

And yes, I do feel like the current software stack of PHP.net is a bit out
of sync with the modern tools that are already there, sorry if I offend
someone.

That's why I think that the next major version of PHP should happen
sooner rather that later. I'm a strong believer that the current engine is
hard to maintain and document and very few people know most of it.

PHP 5.5 should be the last 5.X release then you should announce that
PHP 6 needs more volunteers for a better (faster) parser, people who
can help you on documenting it and so on.

Just make PHP 6.0 a PHP 5.5 that's clean under the hood, maybe
even brings some performance improvements along the way and that's
it. You already know what are the requirements for everything, you
already have feedback on what the community wants in the future,
so why not help yourself by doing something that's clean and along
the way will help you get more contributors?

Also please see my other suggestions on how you could get more
support from the users.



Best regards.

Florin Patan
https://github.com/dlsniper

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Alexey Zakhlestin]

On 21.02.2013, at 20:08, Levi Morrison  wrote:

>> Personally I would love to see more RFCs focusing on performance and
>> less on syntax changes.
> 
> Some recent tests I performed indicate that JavaScript and Dart are
> both significantly faster than PHP when working with just arrays and
> numbers. If anyone is interested I can provide the test code for more
> scrutiny.  I'd like to see more performance enhancements but I am not
> against other enhancements as well.

That is expected. Both of them use JIT-compilation, which is not present in PHP.
There was some effort to implement PHP in PyPy/RPython, but it is not active
http://morepypy.blogspot.ru/2012/07/hello-everyone.html


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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[David Soria Parra]

On 2013-02-21, Rasmus Lerdorf  wrote:
> Personally I would love to see more RFCs focusing on performance and
> less on syntax changes. Of course, a syntax change RFC, and even the
> initial (often shaky) implementation of a syntax-related change is much
> much easier to whip up than the deep analysis, profiling and creativity
> required to find and come up with ways to make a complex piece of code
> faster or use less memory.

+1.

I think that the RFC process did the project very good and enabled new
people and their patches into the project. Nevertheless we should be
aware that a scripting language needs to be robust and fast. The more
language syntax we add, the more complex the language gets and therefore
it's quality as a very good beginners language. Also we just end up in the
troubles we had over the last years when one could just hope that xdebug
will catch up with new language changes (thanks to derick it usually does),
and one knew that APC will not work.

A lot of the language features in the last years didn't just make some
people happy but also made others unhappy as they couldn't use the new
language in production (and thats what counts). People are stuck with
5.3 atm because there is no opcode cache for 5.4 and the only good news
for them is that the ZO+ RFC focuses and robustness and performance so
the users will still have an opcache for a new version once 5.3 is EOL
(in a year). (and i am not even talking about the headache everyone is
already talking about because they used a lot of apc caching functions
in their code and therefore are stuck with 5.3 for another 2 years and
can just rely on distros for patching).

So plesae when one talks about the userbase, make sure you just dont
see you part of the bubble but all the others who are struggling
with recent changes already.

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Ferenc Kovacs]

replying inline


I think it would be helpful to have something like a roadmap with various
> features and changes both in regards to language and features as well
> as performance.
>

We have discussed before and the problem is the nature of the project: it
is an open source project where the contribution comes from the spare time
of the volunters (with a couple of exceptions like people from Oracle
working on the mysql drivers/docs etc.).
So we can try and plan ahead, but in the end we can only release what we
have, and there are no guarantees that somebody will do the job (or do in
in a reasonable timeframe).
PHP6 was an example of a release where we didn't timeboxed, but
feature-boxed, and I think that even without the unicode part, it would
still take too long or would have to break some promises.
Some of the open source project do something in-between, not promising
exact features/ideas for a given release but selecting a couple of
areas/aspects where the release should improve on the current situation:
that could also work imo.


> Also, having a clear line of when features will be deprecated then removed
> will go a long way to help out users while writing their software. That
> way,
> people would know what to expect from the language and when it would
> be the time to upgrade.
>

I think that it isn't necessary a bad thing that we aren't forced to tell
beforehand than a given deprecated version will be removed in which
version, because this way we can push the decision to a later date, when we
have more information to select the best option.
I think that Linus had a really good job explaining that in the first
chapter of
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/ManagementStyle



>
> You could use the example of JetBrains and how they manage their
> products via their issue tracker, http://youtrack.jetbrains.com/issues/WI
> in which everyone that is not part of the core team can 'vote' for a
> feature
> or bug or what not and participate in a threaded discussion in a simpler
> manner.

This would bring you a nicer interface that the current ones while being
> able to also gauge the community interest in certain issues.
>

We already have comments and voting (and ordering on the votes) in the
issue tracker, but if you think that you can improve on the interface, feel
free to send a pull request, I'm sure that there is much room for
improvements, especially in the UI/UX part.


>
> I think if the PHP group would ask JetBrains for their software for free,
> they wouldn't say no and I gave them as an example because I'm using
> their beta software since it the second is out on their download servers
> and I'm reporting every crash that I can as they made it really easy for
> me to help them out.
>

Not sure how this is related to the discussion, but we already got some
licenses from JetBrains (AFAIR Shein Alexey handled that for the phpdoc
team).


>
> And yes, I do feel like the current software stack of PHP.net is a bit out
> of sync with the modern tools that are already there, sorry if I offend
> someone.
>

it is, and it is a chicken and egg problem:
even though that the usual "my C-fu is weak" argument doesn't apply there,
we still lack contributors, and the archaic nature of the current codebase
doesn't really helps bringing in new people.
even if a newcomer would come around with a rewrite of the current
bugtracker based on some modern framework (ZF2/sf2/etc.), it would be a
hard decision, because who who knows what new bugs that codebase has and
there would be a real issue if the original author leaves and there would
be no people left having familiar with the codebase.
the current codebase sucks, but it had time for the bugs to surface, and
the people who work on it are familiar with it.
there is also an issue, that most of the php.net infrastructure is older
than any other framework lifecycle would provide, so switching to a 3rd
party framework would require more maintainence work (ofc. it would also
have advantages like better documentation and people outside of the project
would have an easier time to jump into contributing to it).


>
> That's why I think that the next major version of PHP should happen
> sooner rather that later. I'm a strong believer that the current engine is
> hard to maintain and document and very few people know most of it.
>

I'm a little bit confused, so you are talking about the PHP.net software
stack or about the toolchain/stack used for the development of the language?
I think that the current documentation team is doing a fine job (ofc. there
is also room for improvement, like better/tigher integration/communication
between the php-core and the documentation team),


>
> PHP 5.5 should be the last 5.X release then you should announce that
> PHP 6 needs more volunteers for a better (faster) parser, people who
> can help you on documenting it and so on.
>

I think that we definitely need to be more engaging for the po

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal Chevrel]

Le 21/02/2013 18:56, Ferenc Kovacs a écrit :


it is, and it is a chicken and egg problem:
even though that the usual "my C-fu is weak" argument doesn't apply there,
we still lack contributors, and the archaic nature of the current codebase
doesn't really helps bringing in new people.
even if a newcomer would come around with a rewrite of the current
bugtracker based on some modern framework (ZF2/sf2/etc.), it would be a
hard decision, because who who knows what new bugs that codebase has and
there would be a real issue if the original author leaves and there would
be no people left having familiar with the codebase.
the current codebase sucks, but it had time for the bugs to surface, and
the people who work on it are familiar with it.


Maybe using a bug tracking system that is maintained by another project 
would be a good idea?


I am specifically thinking of Bugzilla which is already used by many 
open source projects. It has a lot more features than your current bug 
tracking system, it scales for large projects and it has a few Mozilla 
employees working full time on it.


Pascal

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Michael Shadle]

On Thu, Feb 21, 2013 at 10:13 AM, Pascal Chevrel  wrote:

> I am specifically thinking of Bugzilla which is already used by many open
> source projects. It has a lot more features than your current bug tracking
> system, it scales for large projects and it has a few Mozilla employees
> working full time on it.

every bugzilla instance I've seen is obnoxious, ugly, too many
options, etc. It's also written in that old, archaic language that PHP
replaced.

Ask the question: what is the current bug system not meeting?

probably needs a couple tweaks is all. I bet it's written in PHP, too.
Fancy that?

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Johannes Schlüter]

On Thu, 2013-02-21 at 19:13 +0100, Pascal Chevrel wrote:
> 
> I am specifically thinking of Bugzilla which is already used by many 
> open source projects. It has a lot more features than your current
> bug 
> tracking system, it scales for large projects and it has a few
> Mozilla 
> employees working full time on it.
> 
I'm a passive user of bugzilla, not involved with any project using it
but every time I have to report a bug on a project using it I think
twice, why do I have to register and run away if I have to remember the
password I used 2 years ago when reporting my last bug.

bugs.php.net might not be as shiny as others but it makes reporting
easy, fill in a captcha and you are done, no registration or such, you
might even use a fake mail address (not that it necessarily helps to be
unreachable for getting things resolved)

And then there is a religious thing: Bugzilla is written in a legacy
language ;-)

And yes. it has some rough edges, but it get's it's job done, integrates
with out user system, our "what's the current version"-notification
system, ...

johannes



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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Lester Caine]

Arvids Godjuks wrote:

In principle, as a user-land developer, I agree with the motion. It's too
much fancy new shiny stuff lately and no actual improvement on the old
stuff that really needs fixing or updating/rewriting (PDO anyone? Years
behind every db driver extension there is in PHP, and as far as I'm
concerned - it should be dropped and concentrate on standardize the db
extension public API).


A BIG +1 on that ... there are a number of better options which would actually 
be a step forward rather than dragging everything back to the past with PDO's 
limited API !


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Johannes Schlüter]

On Thu, 2013-02-21 at 17:06 +0100, Marco Pivetta wrote:
> On 21 February 2013 17:04, Johannes Schlüter  wrote:
> 
> > The quoted business decision was "We want something stable and fast", an
> > emphasis of fixing bugs over adding new ones. This sounds sane to me.

> Doesn't exclude new features then: so what is this all about?

  * We have limited development resources
  * Developers can either fix bugs and tune code or add features
  * All new features go through different rounds of fixing newly
introduced bugs
  * All new features increase the amount of things to maintain
long-term

I'm not against new features, but sometimes I wonder about the focus.

johannes



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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Rasmus Lerdorf]

On 02/21/2013 01:04 PM, Johannes Schlüter wrote:
> On Thu, 2013-02-21 at 17:06 +0100, Marco Pivetta wrote:
>> On 21 February 2013 17:04, Johannes Schlüter  wrote:
>>
>>> The quoted business decision was "We want something stable and fast", an
>>> emphasis of fixing bugs over adding new ones. This sounds sane to me.
> 
>> Doesn't exclude new features then: so what is this all about?
> 
>   * We have limited development resources
>   * Developers can either fix bugs and tune code or add features
>   * All new features go through different rounds of fixing newly
> introduced bugs
>   * All new features increase the amount of things to maintain
> long-term
> 
> I'm not against new features, but sometimes I wonder about the focus.

Traits is a good example of that. We, and by we I mean Dmitry, are still
fixing problems with Traits and we are closing in on 5 years after the
initial proposal in 2008. And Traits is sort of middle of the road in
terms of complexity. We have had more complex things proposed and we
still only have one Dmitry.

-Rasmus

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Crypto Compress]

Hello List,

how about sort of Tick-Tock development model?

Tick = optimize/bugfix
Tock = shiny new features

e.g. http://en.wikipedia.org/wiki/Intel_Tick-Tock

cryptocompress

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Stas Malyshev]

Hi!

> F.e., how long have we been battled for annotations? With all
> respects, it is about being blind and stubborn to say that PHP should
> not have annotations. But due to some "I'm happy with what we have

It is about being blind and stubborn to hold opinion different than
yours. And *this* not an opinion but a fact. Got it.

> This is not about borking the language with useless features. This is
> not about being on the cutting edge. this is about catching up with
> the competition.

"Keeping up with the Joneses" is not a good idea in personal life, and
is not a good idea in language design. Not everything Joneses have we
should have, just because they do. You have to have better reasons.
Sometimes there are better reasons, and we do borrow all the time. But
doing that *just* because they have it makes little sense. *When* we
decide that it makes sense for PHP, then we can look at how others do it
and see if it translates.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Martin Keckeis]

2013/2/21 Johannes Schlüter 

> On Thu, 2013-02-21 at 19:13 +0100, Pascal Chevrel wrote:
> >
> > I am specifically thinking of Bugzilla which is already used by many
> > open source projects. It has a lot more features than your current
> > bug
> > tracking system, it scales for large projects and it has a few
> > Mozilla
> > employees working full time on it.
> >
> I'm a passive user of bugzilla, not involved with any project using it
> but every time I have to report a bug on a project using it I think
> twice, why do I have to register and run away if I have to remember the
> password I used 2 years ago when reporting my last bug.
>
> bugs.php.net might not be as shiny as others but it makes reporting
> easy, fill in a captcha and you are done, no registration or such, you
> might even use a fake mail address (not that it necessarily helps to be
> unreachable for getting things resolved)
>
> And then there is a religious thing: Bugzilla is written in a legacy
> language ;-)
>
> And yes. it has some rough edges, but it get's it's job done, integrates
> with out user system, our "what's the current version"-notification
> system, ...
>
>
I think there may come many critics maybe, but why not move those things
also to github?
It's used by many people. it works, it's easy!

Zend Framework also done the move from SVN, signing a CLA, own Bug tracking
system. to github and I think it couldn't be better now!

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Johannes Schlüter]

On Fri, 2013-02-22 at 08:44 +0100, Martin Keckeis wrote:

> I think there may come many critics maybe, but why not move those things
> also to github?
> It's used by many people. it works, it's easy!

It is easily two steps back. Yay! (Tags are funny but don't help with
categorization of bugs on PHP's scale, the initial comment was on
improving the Voting, github has no voting at all, ...)

So if you have issues with the bug tracker please log a bug ...

johannes



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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Ferenc Kovacs]

On Fri, Feb 22, 2013 at 8:44 AM, Martin Keckeis
wrote:

> 2013/2/21 Johannes Schlüter 
>
> > On Thu, 2013-02-21 at 19:13 +0100, Pascal Chevrel wrote:
> > >
> > > I am specifically thinking of Bugzilla which is already used by many
> > > open source projects. It has a lot more features than your current
> > > bug
> > > tracking system, it scales for large projects and it has a few
> > > Mozilla
> > > employees working full time on it.
> > >
> > I'm a passive user of bugzilla, not involved with any project using it
> > but every time I have to report a bug on a project using it I think
> > twice, why do I have to register and run away if I have to remember the
> > password I used 2 years ago when reporting my last bug.
> >
> > bugs.php.net might not be as shiny as others but it makes reporting
> > easy, fill in a captcha and you are done, no registration or such, you
> > might even use a fake mail address (not that it necessarily helps to be
> > unreachable for getting things resolved)
> >
> > And then there is a religious thing: Bugzilla is written in a legacy
> > language ;-)
> >
> > And yes. it has some rough edges, but it get's it's job done, integrates
> > with out user system, our "what's the current version"-notification
> > system, ...
> >
> >
> I think there may come many critics maybe, but why not move those things
> also to github?
> It's used by many people. it works, it's easy!
>
> Zend Framework also done the move from SVN, signing a CLA, own Bug tracking
> system. to github and I think it couldn't be better now!
>

it would require some changes in our process and infrastructure:

   - currently the bugtracker supports private bugs (mostly 0day security
   reports) AFAIK github doesn't have that, so we would have to use another
   channel (like using the secur...@php.net alone), which would be worse
   than the current solution when the security bugs (with all of the
   discussion) are opened up after the fix is released
   - currently we don't require a registration for reporting bugs, with the
   github issues the reporter needs to be registered and logged into github.
   - currently the bugtracker authenticates the contributers using their
   php.net credentials, github doesn't provide a way for that, so
   potentially ever contributer should be registered on github and added as a
   collaborator to be able to assign/edit/resolve issues. (and potentially the
   process should be automated, so when a php.net user is approved/granted
   karma he/she should be added to the collaborators automatically, I suppose
   there is a way to do that in the github api).
   - currently the bugtracker supports blocking the comments for a specific
   bug, github doesn't have that kind of feature.
   - currently the bugtracker supports providing version, OS information,
   the github issues doesn't have any way to have custom fields, maybe the
   labels/tags could be (ab)used for this, and we would need to automate this
   so when a new version is added, the label should automatically pushed to
   github.
   - currently the bugtracker supports providing package information, that
   would either require us to split the php-src repo into multiple
   repositories (ext/*, Zend/, etc. this would be a bad idea imo) or we would
   need to use labels for this also(and the labels should.be automatically
   updated when a new package is created).
   - currently the bugtracker supports providing bugtype information(bug,
   feature request, documentation issue, security), see above.
   - currently the bugtracker supports closing the issues with Quick Fixes,
   where there is a predefined comment automatically added to the bug so we
   don't have to copypaste the resolution message for similar bugs (that the
   website/docs related fixes needs time to propagate, that fixing a bug in
   the head means that it will be fixed in a future release etc.), github
   issues doesn't have this kind of feature.

These are the issues(from the top of my head) which need to be resolved
if/when we wanna move the tracker to github.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Ferenc Kovacs]

On Fri, Feb 22, 2013 at 10:39 AM, Johannes Schlüter
wrote:

> On Fri, 2013-02-22 at 08:44 +0100, Martin Keckeis wrote:
>
> > I think there may come many critics maybe, but why not move those things
> > also to github?
> > It's used by many people. it works, it's easy!
>
> It is easily two steps back. Yay! (Tags are funny but don't help with
> categorization of bugs on PHP's scale, the initial comment was on
> improving the Voting, github has no voting at all, ...)
>
> So if you have issues with the bug tracker please log a bug ...
>
>
sigh, yeap, I forgot to mention the voting what we have (reproducible and
importance), github also lacks those.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pierre Joye]

On Tue, Jun 7, 2011 at 1:04 PM, Derick Rethans  wrote:
> Hi,
>
> Short-array syntax, Native JSON, "Currying". I can
> almost only say one thing: WHY?!
>
> And because of that, I'd like to forward a mail by Zeev from a few years
> ago. I think it applies now even more than then:

I'd to disagree.

I love activities on the list, even for features I would never want to
see implemented in php. It is how it works, it is how it should work,
Getting constant new requests, discussing new possible features,
moving forward. Even if it does not mean it has to be uncontrollable
and that we should implement every 2nd request.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Ferenc Kovacs]

On Tue, Jun 7, 2011 at 1:04 PM, Derick Rethans  wrote:

> Hi,
>
> Short-array syntax, Native JSON, "Currying". I can
> almost only say one thing: WHY?!
>
> And because of that, I'd like to forward a mail by Zeev from a few years
> ago. I think it applies now even more than then:
>
> snip

I think that it is better to have healthy discussion about the language,
than to stop accepting feature request at all.
of course we have to carefully select which RFCs are good enough and worthy
for inclusion, and properly introduce them into the language and for the
users.

I really like the current buzz, but maybe there are some people like you,
who are more in favor for the previous flow of conversations(fewer
participants, fewer discussions).

Tyrael

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Andi Gutmans]

Hi Derick and all,

I think we have had some reasonable additions to the language in PHP 5.3 + will 
have a couple of good ones in PHP 5.4. That said, I do agree we should have a 
strong bias against language feature creep unless there is a really strong 
compelling reason.
I do think that an increase of focus on enriching the eco-system around the 
core language esp. PHP extensions will be a lot more valuable. This is 
especially so if we can target many of the up and coming technologies and get 
such extensions production ready to bundle in Core PHP (hence my previous email 
re: adding some modern extensions).

We've benefited in the past from a lot of enhancements and innovation around 
extensions incl. SimpleXML, variety of database, json, datetime, etc... Having 
another wave of really strong core extensions would be very beneficial and 
consistent with our past bias to deliver everything Web developers need 
out-of-the-box.

Hence my suggestion to bundle MongoDB extension and possibly work on additional 
extensions. Some of my suggestions probably rightfully didn't get much interest 
such as Thrift.

Maybe we should consider making a list of extensions we think could be 
beneficial and the new mentorship program can actually help deliver some of 
them?

Stas, on a different note, weren't we going to roll a 5.4 alpha?
Andi

>-Original Message-
>From: Derick Rethans [mailto:der...@php.net]
>Sent: Tuesday, June 07, 2011 4:05 AM
>To: PHP Developers Mailing List
>Subject: [PHP-DEV] Give the Language a Rest motion (fwd)
>
>Hi,
>
>Short-array syntax, Native JSON, "Currying". I can almost only say one thing:
>WHY?!
>
>And because of that, I'd like to forward a mail by Zeev from a few years ago. I
>think it applies now even more than then:
>
>-- Forwarded message --
>Date: Thu, 09 Mar 2006 12:57:32 +0200
>From: Zeev Suraski 
>To: internals@lists.php.net
>Subject: [PHP-DEV] Give the Language a Rest motion
>
>I'd like to raise a motion to 'Give the Language a Rest'.
>
>Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
>and 2 more major versions since then, and we're still heatedly debating on
>adding new syntactical, core level features.
>
>Is it really necessary?  I'd say in almost all cases the answer's no, and a 
>bunch of
>cases where a new feature could be useful does not constitute a good enough
>reason to add a syntax level feature.  We might have to account for new
>technologies, or maybe new ways of thinking that might arise, but needless to
>say, most of the stuff we've been dealing with in recent times doesn't exactly
>fall in the category of cutting edge technology.
>
>My motion is to make it much, much more difficult to add new syntax-level
>features into PHP.  Consider only features which have significant traction to a
>large chunk of our userbase, and not something that could be useful in some
>extremely specialized edge cases, usually of PHP being used for non web stuff.
>
>How do we do it?  Unfortunately, I can't come up with a real mechanism to
>'enforce' a due process and reasoning for new features.
>
>Instead, please take at least an hour to bounce this idea in the back of your
>mind, preferably more.  Make sure you think about the full context, the huge
>audience out there, the consequences of  making the learning curve steeper with
>every new feature, and the scope of the goodness that those new features bring.
>Consider how far we all come and how successful the PHP language is today, in
>implementing all sorts of applications most of us would have never even thought
>of when we created the language.
>
>Once you're done thinking, decide for yourself.  Does it make sense to be
>discussing new language level features every other week?  Or should we,
>perhaps, invest more in other fronts, which would be beneficial for a far 
>bigger
>audience.  The levels above - extensions to keep with the latest technologies,
>foundation classes, etc.  Pretty much, the same direction other mature
>languages went to.
>
>To be clear, and to give this motion higher chances of success, I'm not talking
>about jump.  PHP can live with jump, almost as well as it could live without it
>:)  I'm talking about the general sentiment.
>
>Zeev
>
>--
>http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation:
>http://xdebug.org/donate.php
>twitter: @derickr and @xdebug
>
>--
>PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
>http://www.php.net/unsub.php


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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pierre Joye]

On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans  wrote:

> Hence my suggestion to bundle MongoDB extension and possibly work on 
> additional extensions. Some of my suggestions probably rightfully didn't get 
> much interest such as Thrift.

See my comment in your other thread and below.

> Maybe we should consider making a list of extensions we think could be 
> beneficial and the new mentorship program can actually help deliver some of 
> them?

I do not thnk it is a good thing to begin a discussion about this
exact topic and then totally ignore it.

I also think that it is somehow wrong to post something asking to do
not propose new things when we finally have more people involved in
proposals and discussions. Maybe that's just me me but I do think that
the main problem we have (besides the ones we identified and try to
fix right now) is the complete lack of open discussions about possible
new features, in this list with new or existing contributors.

-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Andi Gutmans]

>-Original Message-
>From: Pierre Joye [mailto:pierre@gmail.com]
>Sent: Wednesday, June 15, 2011 2:33 AM
>To: Andi Gutmans
>Cc: Derick Rethans; PHP Developers Mailing List
>Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
>
>On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans  wrote:
>
>> Hence my suggestion to bundle MongoDB extension and possibly work on
>additional extensions. Some of my suggestions probably rightfully didn't get
>much interest such as Thrift.
>
>See my comment in your other thread and below.
>
>> Maybe we should consider making a list of extensions we think could be
>beneficial and the new mentorship program can actually help deliver some of
>them?
>
>I do not thnk it is a good thing to begin a discussion about this exact topic 
>and
>then totally ignore it.
>

I think it got lost in the very long and varying discussions. Will dig up and 
take a look. I had a couple of hectic weeks.

>I also think that it is somehow wrong to post something asking to do not 
>propose
>new things when we finally have more people involved in proposals and
>discussions. Maybe that's just me me but I do think that the main problem we
>have (besides the ones we identified and try to fix right now) is the complete
>lack of open discussions about possible new features, in this list with new or
>existing contributors.

I did not say we should not propose or have discussions (I am in favor of 
adding [] for arrays for example). But I am saying the bias should be not to 
include new language functionality unless it has very broad appeal & serious 
upside impact. The bias should be against feature creep.

Andi

>
>--
>Pierre
>
>@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[dukeofgaming]

Hi,

I think that —in any context— the "if it aint broke don't fix it" is a very
depressing attitude to have, and a very wrong one in any open source
community.

If the signal to noise ratio is the problem, I think its better to focus on
that problem, not shutting down the signal. If PHP is a resource crunched
project, I think its better to focus on that problem, not rejecting feature
requests.

(I might appear as impertinent with what I'm going to say, but bear with me,
I'm being well-intentioned and mean no offense; just want to be honest).

Regarding the signal to noise ratio, I have one question: how did traits get
accepted?, having seen the kind of conversations in the lists it makes
almost no sense to me how something so "radical" and complex could make its
way to PHP so quickly and a simple and convenient thing like a short array
syntax cannot, and something so basic as annotations raises so much
pointless (just not to say ignorant) debate. Was it the to-the-point RFC and
solid patch?, was it that the conversations were just on another level so
not anyone could just say —or troll— "traits are no solution! *spit*, lets
do aspects instead!". I know it took some time, but while lurking the lists
IIRC I never saw any opposition to traits... could anyone tell me what was
the magic behind this?, could it be repeated?.

Regarding resources, I think this is one of the main things rendering the
community unhealthy (at least it feels like that to me) and I even feel
bitterness in the air. I think that the definite solution to this is a DVCS
like git and hosting the code at github, or like mercurial and hosting the
code at bitbucket, please don't be angered at this suggestion (as I know the
switch to SVN is a fairly recent one), you can ask around SVN geeks that
went the distributed way and they will tell you things, wonderful things of
how they don't know how could they could endure that much with that in their
project, and if its an open source one, how much the switch has done in
favor of contributions.

Regardless of everything, I like that the PHP community has so much passion
and energy, sometimes in a not constructive way, but that is a good problem
to have in my opinion, really, don't take it for granted, it just needs a
little direction.

Best regards,

David Vega

On Wed, Jun 15, 2011 at 8:46 PM, Andi Gutmans  wrote:

> >-Original Message-
> >From: Pierre Joye [mailto:pierre@gmail.com]
> >Sent: Wednesday, June 15, 2011 2:33 AM
> >To: Andi Gutmans
> >Cc: Derick Rethans; PHP Developers Mailing List
> >Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
> >
> >On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans  wrote:
> >
> >> Hence my suggestion to bundle MongoDB extension and possibly work on
> >additional extensions. Some of my suggestions probably rightfully didn't
> get
> >much interest such as Thrift.
> >
> >See my comment in your other thread and below.
> >
> >> Maybe we should consider making a list of extensions we think could be
> >beneficial and the new mentorship program can actually help deliver some
> of
> >them?
> >
> >I do not thnk it is a good thing to begin a discussion about this exact
> topic and
> >then totally ignore it.
> >
>
> I think it got lost in the very long and varying discussions. Will dig up
> and take a look. I had a couple of hectic weeks.
>
> >I also think that it is somehow wrong to post something asking to do not
> propose
> >new things when we finally have more people involved in proposals and
> >discussions. Maybe that's just me me but I do think that the main problem
> we
> >have (besides the ones we identified and try to fix right now) is the
> complete
> >lack of open discussions about possible new features, in this list with
> new or
> >existing contributors.
>
> I did not say we should not propose or have discussions (I am in favor of
> adding [] for arrays for example). But I am saying the bias should be not to
> include new language functionality unless it has very broad appeal & serious
> upside impact. The bias should be against feature creep.
>
> Andi
>
> >
> >--
> >Pierre
> >
> >@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Andi Gutmans]

What I am saying is if we accepted even 50% of what people felt very passionate 
about because their "favorite language of the day" has it then PHP would become 
overly complex, bloated and very challenging for users to pick up. C++ for 
example was a good language but is a good example of trying to do too much and 
getting overly complex over time (at least in my opinion).

I do think we should have new feature discussions and need to ensure PHP 
evolves with the market and its users but have to ensure that we still keep it 
simple, easy to adopt and maintainable. Also, I think we do not need 100 ways 
of doing the same thing. Choice is good but too much choice is not. 

As I said in my previous email, while I think there are areas we can and should 
innovate in and evolve the core language I believe a lot of the innovation also 
has to happen at the framework and extension-level. I do not think there's a 
resource issue at the language level. When a new feature does get slated to be 
included we always have plenty of resources deployed on it to harden it and 
make sure it gets into the core vm in the right way (it is almost never the 
same as the original patch).

I do think having more people work on extensions for some of the up and coming 
technologies would be super valuable. Seems like everyone wants to try and get 
their favorite language feature in but less are stepping up to work on 
extensions. What can you contribute?

Andi

From: dukeofgaming [mailto:dukeofgam...@gmail.com] 
Sent: Wednesday, June 15, 2011 7:36 PM
To: Andi Gutmans
Cc: Pierre Joye; Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)

Hi,

I think that -in any context- the "if it aint broke don't fix it" is a very 
depressing attitude to have, and a very wrong one in any open source community.

If the signal to noise ratio is the problem, I think its better to focus on 
that problem, not shutting down the signal. If PHP is a resource crunched 
project, I think its better to focus on that problem, not rejecting feature 
requests.

(I might appear as impertinent with what I'm going to say, but bear with me, 
I'm being well-intentioned and mean no offense; just want to be honest).

Regarding the signal to noise ratio, I have one question: how did traits get 
accepted?, having seen the kind of conversations in the lists it makes almost 
no sense to me how something so "radical" and complex could make its way to PHP 
so quickly and a simple and convenient thing like a short array syntax cannot, 
and something so basic as annotations raises so much pointless (just not to say 
ignorant) debate. Was it the to-the-point RFC and solid patch?, was it that the 
conversations were just on another level so not anyone could just say -or 
troll- "traits are no solution! *spit*, lets do aspects instead!". I know it 
took some time, but while lurking the lists IIRC I never saw any opposition to 
traits... could anyone tell me what was the magic behind this?, could it be 
repeated?.

Regarding resources, I think this is one of the main things rendering the 
community unhealthy (at least it feels like that to me) and I even feel 
bitterness in the air. I think that the definite solution to this is a DVCS 
like git and hosting the code at github, or like mercurial and hosting the code 
at bitbucket, please don't be angered at this suggestion (as I know the switch 
to SVN is a fairly recent one), you can ask around SVN geeks that went the 
distributed way and they will tell you things, wonderful things of how they 
don't know how could they could endure that much with that in their project, 
and if its an open source one, how much the switch has done in favor of 
contributions.

Regardless of everything, I like that the PHP community has so much passion and 
energy, sometimes in a not constructive way, but that is a good problem to have 
in my opinion, really, don't take it for granted, it just needs a little 
direction.
Best regards,

David Vega

On Wed, Jun 15, 2011 at 8:46 PM, Andi Gutmans  wrote:
>-Original Message-
>From: Pierre Joye [mailto:pierre@gmail.com]
>Sent: Wednesday, June 15, 2011 2:33 AM
>To: Andi Gutmans
>Cc: Derick Rethans; PHP Developers Mailing List
>Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
>
>On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans  wrote:
>
>> Hence my suggestion to bundle MongoDB extension and possibly work on
>additional extensions. Some of my suggestions probably rightfully didn't get
>much interest such as Thrift.
>
>See my comment in your other thread and below.
>
>> Maybe we should consider making a list of extensions we think could be
>beneficial and the new mentorship program can actually help deliver some of
>them?
>
>I do not thnk it is a good thing to begin a discussion about thi

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 04:36, dukeofgaming a écrit :
> Hi,
> 
> I think that —in any context— the "if it aint broke don't fix it" is a very
> depressing attitude to have, and a very wrong one in any open source
> community.

  What I feel depressing is the urge of the PHP core team to fix working 
features
instead of focusing on the 1800 open bug tickets.

  On every PHP project I work on I had to find workarounds because PHP crashes.
Behaviour bugs (feature not working as intented) are annoying but memory leaks 
and
memory corruptions are just a no no no in production environnement. The only way
to call PHP when its memory leaks and get corrupted is to call it via CGI which
is much too slow for a production server.

  What I need is a very stable language on which I can rely and I'm very sad to
to say PHP is getting worse and worse on that point of view versions after 
versions.

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Stas Malyshev]

Hi!


   On every PHP project I work on I had to find workarounds because PHP crashes.
Behaviour bugs (feature not working as intended) are annoying but memory leaks 
and
memory corruptions are just a no no no in production environment. The only way


A key to fixing memory corruption is providing good bug reports - with 
backtraces, valgrind reports, etc. If you have such reports and nothing 
happens to them - you may want to try to raise the profile of bug 
reports that are bothering you by mentioning them on the list and 
calling for volonteers to fix them. Usually if bug is in frequently used 
module and  reproduceable, there would be somebody who can fix it.



   What I need is a very stable language on which I can rely and I'm very sad to
to say PHP is getting worse and worse on that point of view versions after 
versions.


I can not contradict your experience, it is what it is, but my 
experience for years working with PHP was exactly the opposite.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 07:23, Stas Malyshev a écrit :
> Hi!
> 
>> On every PHP project I work on I had to find workarounds because
>> PHP crashes. Behaviour bugs (feature not working as intended) are
>> annoying but memory leaks and memory corruptions are just a no no
>> no in production environment. The only way
> 
> A key to fixing memory corruption is providing good bug reports -
> with backtraces, valgrind reports, etc. If you have such reports and
> nothing happens to them - you may want to try to raise the profile of
> bug reports that are bothering you by mentioning them on the list and
> calling for volonteers to fix them. Usually if bug is in frequently
> used module and  reproduceable, there would be somebody who can fix
> it.

  what I did every single time. Among all my bug reports I had one answer
from decoder-...@own-hero.net (thanks to him) who reduced the test case
for a memory leak (bug 54460). I'm not talking about bugs in modules 
but bugs in *core* which can be reproduced with few lines of *core* PHP.

>> What I need is a very stable language on which I can rely and I'm
>> very sad to to say PHP is getting worse and worse on that point of
>> view versions after versions.
> 
> I can not contradict your experience, it is what it is, but my
> experience for years working with PHP was exactly the opposite.

  To tell you the truth, I've been asked to rewrite the framework I
did in Ruby because of these problems. I'm of course very reluctant 
to go that way but in the end I may have no choice :-(

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[dukeofgaming]

On Thu, Jun 16, 2011 at 12:14 AM, Pascal COURTOIS  wrote:

> Le 16/06/2011 04:36, dukeofgaming a écrit :
> > Hi,
> >
> > I think that —in any context— the "if it aint broke don't fix it" is a
> very
> > depressing attitude to have, and a very wrong one in any open source
> > community.
>
>   What I feel depressing is the urge of the PHP core team to fix working
> features
> instead of focusing on the 1800 open bug tickets.
>


Sorry if the question is dumb, but, how many core developers does PHP have?,
how many in total (including non-core contributors)?.

Regards,

David

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Stas Malyshev]

Hi!


   what I did every single time. Among all my bug reports I had one answer
from decoder-...@own-hero.net (thanks to him) who reduced the test case
for a memory leak (bug 54460). I'm not talking about bugs in modules
but bugs in *core* which can be reproduced with few lines of *core* PHP.


I am reading the list pretty closely and I don't remember any emails 
from you raising the question of reproducible corruption bugs recently, 
except indeed for 54460 which seems to be a memory leak, though presence 
of xcache in the trace suggests it may not even be a PHP bug. It talks 
about bug in a template engine containing thousands of lines. This is 
pretty hard work to debug something starting with huge unknown code, so 
no wonder nobody got to it yet. PHP is a volunteer project, and it's not 
easy to find volunteers to dig into thousand lines of unknown code to 
find a bug that may not even be there. It's quite a hard work.


I must have missed other ones. But if they are still reproducible in 5.4 
and you have reproducing code, you're welcome to share on the list. 
Unfortunately, bugs.php.net seems to be down, but once it gets up we 
could look into it and see if we can fix any. As I said, good 
reproduction makes it better.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 08:01, dukeofgaming a écrit :
 
> Sorry if the question is dumb, but, how many core developers does PHP have?,
> how many in total (including non-core contributors)?.

 That's not the point. Whatever the project is, every developer should fix 
existing bugs before even thinking about improving. That's the way I do and
that's why there is no bug I'm aware in my programs.

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Michael Wallner]

On Wed, 15 Jun 2011 23:10:24 -0700, Stas Malyshev wrote:

> Hi!
> 
>>what I did every single time. Among all my bug reports I had one
>>answer


Stas, how I can i finally persuade you to quote the name of the people 
you're replying to? :) I find it very hard to follow any discussion 
you're involved in.

Thanks,
Mike

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[dukeofgaming]

On Thu, Jun 16, 2011 at 1:12 AM, Pascal COURTOIS
wrote:

> Le 16/06/2011 08:01, dukeofgaming a écrit :
>
> > Sorry if the question is dumb, but, how many core developers does PHP
> have?,
> > how many in total (including non-core contributors)?.
>
>  That's not the point. Whatever the project is, every developer should fix
> existing bugs before even thinking about improving. That's the way I do and
> that's why there is no bug I'm aware in my programs.
>
>
I really mean the question, regardless.

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 08:10, Stas Malyshev a écrit :
> Hi!
> 
>> what I did every single time. Among all my bug reports I had one
>> answer from decoder-...@own-hero.net (thanks to him) who reduced
>> the test case for a memory leak (bug 54460). I'm not talking about
>> bugs in modules but bugs in *core* which can be reproduced with few
>> lines of *core* PHP.
> 
> I am reading the list pretty closely and I don't remember any emails
> from you raising the question of reproducible corruption bugs
> recently, except indeed for 54460 which seems to be a memory leak,
> though presence of xcache in the trace suggests it may not even be a
> PHP bug. It talks about bug in a template engine containing thousands
> of lines. This is pretty hard work to debug something starting with
> huge unknown code, so no wonder nobody got to it yet. PHP is a
> volunteer project, and it's not easy to find volunteers to dig into
> thousand lines of unknown code to find a bug that may not even be
> there. It's quite a hard work.

  as I said earlier, test case was reduced to:



 as you can see there's nothing but PHP core instructions in that code.


> I must have missed other ones. But if they are still reproducible in
> 5.4 and you have reproducing code, you're welcome to share on the
> list. Unfortunately, bugs.php.net seems to be down, but once it gets
> up we could look into it and see if we can fix any.

  for memory leaks if the bug is fixed it will not happen again but 
for memory corruption it's something totaly different. The fact that
a bug disapears doesn't mean in any way it has been fixed. 

> As I said, good
> reproduction makes it better.

  I've been debugging in lots of languages including assembly codes 
for over 30 years so I know precisely what you mean. So when it's
possible to reproduce a bug in some known conditions, the wait-and-see
attitude is not a good option because it's very likely that the bug
will disapear. Memory coruptions are much like terrorist attacks: 
you never know where and when it will happen.

  In bug 614904 I submitted a TWO lines program which crashed PHP on
a absolutely standard i386 debian install. I got no answer.
Of course the bug disapeared in following versions of PHP but what is fixed ?
Not as far as I know.


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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Lester Caine]

Pascal COURTOIS wrote:

What I need is a very stable language on which I can rely and I'm
>>  very sad to to say PHP is getting worse and worse on that point of
>>  view versions after versions.

>
>  I can not contradict your experience, it is what it is, but my
>  experience for years working with PHP was exactly the opposite.

>

   To tell you the truth, I've been asked to rewrite the framework I
did in Ruby because of these problems. I'm of course very reluctant
to go that way but in the end I may have no choice:-(


Pascal
I am sure that many people here would be more than happy to hear about 
particular problems you are hitting. Like Stas I have never had problems with 
the stability of PHP5 in 10 years of running it. YES I can get it to crash, but 
it has always told me why and fixing the problem clears that up. I do have sites 
that become unstable, but I have yet to find a situation where PHP was the 
problem ...


My grumble is with having to rewrite code simply because someone has decided 
that what I was doing is no longer acceptable ... if I can run my code with 
display_errors ON then I know I've got clean code :)


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 08:52, Lester Caine a écrit :
 
> Pascal I am sure that many people here would be more than happy to
> hear about particular problems you are hitting.

  Ok, then why when I signal a bug noone cares ?

> Like Stas I have
> never had problems with the stability of PHP5 in 10 years of running
> it.

  PHP5 did not exist 10 years ago ;-)

  Anyway, around 2001 it took me one year (not full time) to find out
there was a memory corruption in PHP. At that time I was using mod_php.
It crashed Apache. 

> YES I can get it to crash, but it has always told me why and
> fixing the problem clears that up. I do have sites that become
> unstable, but I have yet to find a situation where PHP was the
> problem ...

  when you have a bug in PHP it should not ever ever crash PHP and 
unfortunately I encountered that case dozens of times.

 
> My grumble is with having to rewrite code simply because someone has
> decided that what I was doing is no longer acceptable ... if I can
> run my code with display_errors ON then I know I've got clean code
> :)
  
  I 1000% agree
 


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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Lester Caine]

Pascal COURTOIS wrote:

Like Stas I have
never had problems with the stability of PHP5 in 10 years of running
it.


   PHP5 did not exist 10 years ago ;-)

OK coming on 8 years ... seems longer :)
I looked at PHP4, but PHP5 was at release candidate stage so I decided that I'd 
skip straight to that. But I still had to learn PHP4 as people expected 
backwards compatibility. My ISP 1and1 STILL list PHP4 as the default for virtual 
hosting :(



   Anyway, around 2001 it took me one year (not full time) to find out
there was a memory corruption in PHP. At that time I was using mod_php.
It crashed Apache.


YES I can get it to crash, but it has always told me why and
fixing the problem clears that up. I do have sites that become
unstable, but I have yet to find a situation where PHP was the
problem ...


   when you have a bug in PHP it should not ever ever crash PHP and
unfortunately I encountered that case dozens of times.

At least on Linux is just recovers and carries on
The earlier windows stuff I had used to just crash the whole machine. PHP was 
something of a refreshing change ...


I am behind you on getting what we have a lot better. Many thing have been 
pushed in and then forgotten ... like PDO!


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Philip Olson]

On Jun 15, 2011, at 11:34 PM, dukeofgaming wrote:

> On Thu, Jun 16, 2011 at 1:12 AM, Pascal COURTOIS
> wrote:
> 
>> Le 16/06/2011 08:01, dukeofgaming a écrit :
>> 
>>> Sorry if the question is dumb, but, how many core developers does PHP
>> have?,
>>> how many in total (including non-core contributors)?.
>> 
>> That's not the point. Whatever the project is, every developer should fix
>> existing bugs before even thinking about improving. That's the way I do and
>> that's why there is no bug I'm aware in my programs.
>> 
>> 
> I really mean the question, regardless.

It's difficult to say, but there are a total of 1,568 php.net accounts. The 
karma[1] rules aren't straightforward to parse but quickly it shows at least 
194 people with full php-src[2] karma, and 54 humans made 1,971 SVN commits to 
php-src within the last 365 days. Those numbers include tests, so the number of 
~active core developers appears closer to 10-20. Of course this doesn't include 
other parts like PECL and documentation but enough hastily created and probably 
misleading statistics for today.

As for the point of the question, php.net could certainly use more contributors 
and ideally we'd clone Felipe. A lot.

[1] http://svn.php.net/viewvc/SVNROOT/global_avail?view=markup
[2] http://svn.php.net/viewvc/php/php-src/

Regards,
Philip


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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 09:19, Lester Caine a écrit :

>>when you have a bug in PHP it should not ever ever crash PHP and
>> unfortunately I encountered that case dozens of times.
> At least on Linux is just recovers and carries on

 If PHP crashes, yes, it recovers but it's VERY resource and time consumming.
If PHP corrupts some memory, it does not crash fastcgi processes but the next
request(s) behave erratically.
  

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Stas Malyshev]

On 6/15/11 11:38 PM, Pascal COURTOIS wrote:

   In bug 614904 I submitted a TWO lines program which crashed PHP on
a absolutely standard i386 debian install. I got no answer.
Of course the bug disapeared in following versions of PHP but what is fixed ?
Not as far as I know.


614904 doesn't look like real bug number. Must be a typo.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 09:29, Stas Malyshev a écrit :
> On 6/15/11 11:38 PM, Pascal COURTOIS wrote:
>>In bug 614904 I submitted a TWO lines program which crashed PHP on
>> a absolutely standard i386 debian install. I got no answer.
>> Of course the bug disapeared in following versions of PHP but what is fixed ?
>> Not as far as I know.
> 
> 614904 doesn't look like real bug number. Must be a typo.

  ooops, sorry. You're right. It's a bug I submitted to debian because of the 
way
they work with releases having a version with no feature update but including 
security updates, which means the versions in debian distribution are not 
exactly
the ones released. Since debian requires that bug submitted should not be 
submitted
also to program developpers, I complied. May be it was a mistake...

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Stas Malyshev]

On 6/15/11 11:38 PM, Pascal COURTOIS wrote:

   as I said earlier, test case was reduced to:


The leaks you'll be seeing in this code is probably caused by the fact 
that main function (i.e. global context) is not destroyed when exit() is 
called, since . It can be argued as a bug, but very minor one and 
totally unlikely to cause any problems both because the leak is 
minuscule and the fact that memory manager will clean it up anyway on 
shutdown. I would have very hard time believing this very short-time 
leak can cause any problems in any production code.


--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 09:56, Stas Malyshev a écrit :
> On 6/15/11 11:38 PM, Pascal COURTOIS wrote:
>> as I said earlier, test case was reduced to:
> 
> The leaks you'll be seeing in this code is probably caused by the
> fact that main function (i.e. global context) is not destroyed when
> exit() is called, since . It can be argued as a bug, but very minor
> one and totally unlikely to cause any problems both because the leak
> is minuscule and the fact that memory manager will clean it up anyway
> on shutdown.

  If you call "minuscule" a leak that requires more than 128Mb as it
normally requires about 4Mb, then it's minuscule but whatever you name 
it it just does not run.

> I would have very hard time believing this very
> short-time leak can cause any problems in any production code.

  It does
 

  

  

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Stas Malyshev]

Hi!

On 6/16/11 1:05 AM, Pascal COURTOIS wrote:

   If you call "minuscule" a leak that requires more than 128Mb as it
normally requires about 4Mb, then it's minuscule but whatever you name
it it just does not run.


Sorry, if your example generates memory footprint of 128Mb, something is 
seriously wrong with your build. There's no way this code can produce 
128Mb footprint. If it's another code, they we'd need to investigate 
what causes that leak, which must be different from the one this code 
produces.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 10:12, Stas Malyshev a écrit :
> Hi!
> 
> On 6/16/11 1:05 AM, Pascal COURTOIS wrote:
>> If you call "minuscule" a leak that requires more than 128Mb as it 
>> normally requires about 4Mb, then it's minuscule but whatever you
>> name it it just does not run.
> 
> Sorry, if your example generates memory footprint of 128Mb, something
> is seriously wrong with your build. There's no way this code can
> produce 128Mb footprint. If it's another code, they we'd need to
> investigate what causes that leak,

  that's a deal. I have no time right now but I will summerize on tuesday 
the whole thing that leaded to this code. 

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pierre Joye]

On Thu, Jun 16, 2011 at 3:46 AM, Andi Gutmans  wrote:
>>-Original Message-
>>From: Pierre Joye [mailto:pierre@gmail.com]
>>Sent: Wednesday, June 15, 2011 2:33 AM
>>To: Andi Gutmans
>>Cc: Derick Rethans; PHP Developers Mailing List
>>Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
>>
>>On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans  wrote:
>>
>>> Hence my suggestion to bundle MongoDB extension and possibly work on
>>additional extensions. Some of my suggestions probably rightfully didn't get
>>much interest such as Thrift.
>>
>>See my comment in your other thread and below.
>>
>>> Maybe we should consider making a list of extensions we think could be
>>beneficial and the new mentorship program can actually help deliver some of
>>them?
>>
>>I do not thnk it is a good thing to begin a discussion about this exact topic 
>>and
>>then totally ignore it.
>>
>
> I think it got lost in the very long and varying discussions. Will dig up and 
> take a look. I had a couple of hectic weeks.

It was not a long discussion and you began this thread :)
http://news.php.net/php.internals/52898

>>I also think that it is somehow wrong to post something asking to do not 
>>propose
>>new things when we finally have more people involved in proposals and
>>discussions. Maybe that's just me me but I do think that the main problem we
>>have (besides the ones we identified and try to fix right now) is the complete
>>lack of open discussions about possible new features, in this list with new or
>>existing contributors.
>
> I did not say we should not propose or have discussions (I am in favor of 
> adding [] for arrays for example). But I am saying the bias should be not to 
> include new language functionality unless it has very broad appeal & serious 
> upside impact. The bias should be against feature creep.

Right, that's why we introduce a voting RFC in addition to the release
RFC, with some "large majority" concept. However I still think that
such posts are inappropriate, timely and generally, while being of
freedom of speak ;-)

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Johannes Schlüter]

On Thu, 2011-06-16 at 08:12 +0200, Pascal COURTOIS wrote:
> Le 16/06/2011 08:01, dukeofgaming a écrit :
>  
> > Sorry if the question is dumb, but, how many core developers does PHP have?,
> > how many in total (including non-core contributors)?.
> 
>  That's not the point. Whatever the project is, every developer should fix 
> existing bugs before even thinking about improving. That's the way I do and
> that's why there is no bug I'm aware in my programs.

Feel free to contribute. PHP is driven by volunteers spending their free
time on it. For many it is more fun to implement new stuff they probably
"need" than fixing bugs in some code which has some side effects which
are not always easy to predict and which they actually don't use.

johannes



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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 11:36, Johannes Schlüter a écrit :
> On Thu, 2011-06-16 at 08:12 +0200, Pascal COURTOIS wrote:
>> Le 16/06/2011 08:01, dukeofgaming a écrit :
>>  
>>> Sorry if the question is dumb, but, how many core developers does PHP have?,
>>> how many in total (including non-core contributors)?.
>>
>>  That's not the point. Whatever the project is, every developer should fix 
>> existing bugs before even thinking about improving. That's the way I do and
>> that's why there is no bug I'm aware in my programs.
> 
> Feel free to contribute. PHP is driven by volunteers spending their free
> time on it.

  I know. I also have a GPL project. Nonetheless some societies use it,
and some people rely on it to get paid. I have absolutely no legal contract
with anyone but I have a moral contract and when I'm signaled a bug, it is 
mostly
fixed within few hours. I just can't imagine replying to a bug submission
"Hey guy, its a free project. Why don't you fix it yourself ?"
My conscience tells me to not release a program if people using it can
shoot themself in the foot.
  
> For many it is more fun to implement new stuff they probably
> "need" than fixing bugs in some code which has some side effects which
> are not always easy to predict and which they actually don't use.

 If you followed the thread you have seen the reduced test case is
VERY short and the ONLY constructions involved are user functions and
exceptions. FULL STOP. Not even a single addition nor a loop nor nothing.
I can't imagine nobody uses user functions and exceptions.

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pierre Joye]

2011/6/16 Pascal COURTOIS :

>  I know. I also have a GPL project. Nonetheless some societies use it,
> and some people rely on it to get paid. I have absolutely no legal contract
> with anyone but I have a moral contract and when I'm signaled a bug, it is 
> mostly
> fixed within few hours. I just can't imagine replying to a bug submission
> "Hey guy, its a free project. Why don't you fix it yourself ?"
> My conscience tells me to not release a program if people using it can
> shoot themself in the foot.

It is not what Johannes said and we do fix bugs every single day. What
Johannes said is that we can't force a volunteer to do something
specific instead of what he wants to do.

It is also totally off topic btw.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 12:12, Pierre Joye a écrit :

> It is not what Johannes said and we do fix bugs every single day. What
> Johannes said is that we can't force a volunteer to do something
> specific instead of what he wants to do.
> 
> It is also totally off topic btw.

  It is really on topic since letting someone insert his wonderful clever 
feature in a project, whatever it is, and not maintain it is a project
management problem. PHP makes me think of a ship with tens of stirring wheels.
Of course no one can be forced to do what he doesn't want but a free 
project doesn't mean unmanaged project and a managed project means 
people with responsibilities. 

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Rasmus]

On 06/16/2011 11:03 AM, Pascal COURTOIS wrote:
>  If you followed the thread you have seen the reduced test case is
> VERY short and the ONLY constructions involved are user functions and
> exceptions. FULL STOP. Not even a single addition nor a loop nor nothing.
> I can't imagine nobody uses user functions and exceptions.

You might also consider that your particular case is rather unique. I
tried your test case and saw no leak after the request. Everything is
freed on request shutdown. That means that for pretty much everyone
doing standard short web requests, this style of code would work
perfectly for them.

-Rasmus

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 12:31, Rasmus a écrit :
> On 06/16/2011 11:03 AM, Pascal COURTOIS wrote:
>>  If you followed the thread you have seen the reduced test case is
>> VERY short and the ONLY constructions involved are user functions and
>> exceptions. FULL STOP. Not even a single addition nor a loop nor nothing.
>> I can't imagine nobody uses user functions and exceptions.
> 
> You might also consider that your particular case is rather unique. I

  since decoder-...@own-hero.net could reduce the case from my original 
program in the conditions I stated, he could obvously detect the leaks.

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Johannes Schlüter]

On Thu, 2011-06-16 at 12:26 +0200, Pascal COURTOIS wrote:
> Le 16/06/2011 12:12, Pierre Joye a écrit :
> 
> > It is not what Johannes said and we do fix bugs every single day. What
> > Johannes said is that we can't force a volunteer to do something
> > specific instead of what he wants to do.
> > 
> > It is also totally off topic btw.
> 
>   It is really on topic since letting someone insert his wonderful clever 
> feature in a project, whatever it is, and not maintain it is a project
> management problem. PHP makes me think of a ship with tens of stirring wheels.
> Of course no one can be forced to do what he doesn't want but a free 
> project doesn't mean unmanaged project and a managed project means 
> people with responsibilities. 

We are fixing bugs. We don't accept any new feature. Sometimes we might
accept features in order to motivate contributors hoping they also fix
bugs in the future.

And even if the reproduce case is short: Some things in the engine are
hard to fix, need thought and verification. Some things even can't be
fixed within a "bug fix" release (x.y.z+1) as they require API changes
or such.

And then there are cases where severity is valuated differently. There
are things "we" (whomever that includes) don't consider a use case as a
proper/important use case and focus on other issues while it might be
"critical" for few users ...

We're welcoming people providing bug fixes. We'd love having zero bugs.
But life isn't easy. We also welcome people who go through the bug
reports and verify them, simplify test cases etc. This is also work to
be done. We receive quite a few bug reports per day (well not right now
as the system is down :-/ ) most of them aren't bugs but wrong
expectations, many are probably bugs, few are actual easy to verify
bugs. Going through them also costs quite some time.

johannes


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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Rasmus]

On 06/16/2011 11:40 AM, Pascal COURTOIS wrote:
> Le 16/06/2011 12:31, Rasmus a écrit :
>> On 06/16/2011 11:03 AM, Pascal COURTOIS wrote:
>>>  If you followed the thread you have seen the reduced test case is
>>> VERY short and the ONLY constructions involved are user functions and
>>> exceptions. FULL STOP. Not even a single addition nor a loop nor nothing.
>>> I can't imagine nobody uses user functions and exceptions.
>>
>> You might also consider that your particular case is rather unique. I
> 
>   since decoder-...@own-hero.net could reduce the case from my original 
> program in the conditions I stated, he could obvously detect the leaks.

I'm not saying there aren't any. There are known leaks in compile_file()
when you throw an exception like that, so if you call a huge amount of
these within a single request, you are going to have problems. But that
is not something the average person hits, and again, they are all
free'ed on request shutdown, so it isn't like it is a persistent leak.

eg.

rasmus@x220:~/php-src/branches/PHP_5_3$ USE_ZEND_ALLOC=0 valgrind
--leak-check=full sapi/cli/php pas.php
==17658== Memcheck, a memory error detector
==17658== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==17658== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==17658== Command: sapi/cli/php pas.php
==17658==
==17658==
==17658== HEAP SUMMARY:
==17658== in use at exit: 3,376 bytes in 18 blocks
==17658==   total heap usage: 25,077 allocs, 25,059 frees, 3,952,839
bytes allocated
==17658==
==17658== 9 bytes in 1 blocks are possibly lost in loss record 3 of 16
==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==17658==by 0x78F2DF: _estrndup (zend_alloc.c:2503)
==17658==by 0x78477B: lex_scan (zend_language_scanner.l:1817)
==17658==by 0x7994DF: zendlex (zend_compile.c:4969)
==17658==by 0x77B9B4: zendparse (zend_language_parser.c:3291)
==17658==by 0x77F3BE: compile_file (zend_language_scanner.l:364)
==17658==by 0x601350: phar_compile_file (phar.c:3393)
==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187)
==17658==by 0x75AA52: php_execute_script (main.c:2284)
==17658==by 0x8406D3: main (php_cli.c:1193)
==17658==
==17658== 14 bytes in 1 blocks are possibly lost in loss record 4 of 16
==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==17658==by 0x7A8D9A: zend_str_tolower_dup (zend_operators.c:1884)
==17658==by 0x79B36E: zend_do_begin_function_call (zend_compile.c:1571)
==17658==by 0x77E64B: zendparse (zend_language_parser.y:671)
==17658==by 0x77F3BE: compile_file (zend_language_scanner.l:364)
==17658==by 0x601350: phar_compile_file (phar.c:3393)
==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187)
==17658==by 0x75AA52: php_execute_script (main.c:2284)
==17658==by 0x8406D3: main (php_cli.c:1193)
==17658==
==17658== 17 bytes in 1 blocks are possibly lost in loss record 5 of 16
==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==17658==by 0x78F2DF: _estrndup (zend_alloc.c:2503)
==17658==by 0x78059A: lex_scan (zend_language_scanner.l:1695)
==17658==by 0x7994DF: zendlex (zend_compile.c:4969)
==17658==by 0x77B9B4: zendparse (zend_language_parser.c:3291)
==17658==by 0x77F3BE: compile_file (zend_language_scanner.l:364)
==17658==by 0x601350: phar_compile_file (phar.c:3393)
==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187)
==17658==by 0x75AA52: php_execute_script (main.c:2284)
==17658==by 0x8406D3: main (php_cli.c:1193)
==17658==
==17658== 648 (232 direct, 416 indirect) bytes in 1 blocks are
definitely lost in loss record 15 of 16
==17658==at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==17658==by 0x77F344: compile_file (zend_language_scanner.l:334)
==17658==by 0x601350: phar_compile_file (phar.c:3393)
==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187)
==17658==by 0x75AA52: php_execute_script (main.c:2284)
==17658==by 0x8406D3: main (php_cli.c:1193)
==17658==
==17658== 1,680 bytes in 1 blocks are possibly lost in loss record 16 of 16
==17658==at 0x4C290A4: realloc (vg_replace_malloc.c:525)
==17658==by 0x7A2273: pass_two (zend_opcode.c:380)
==17658==by 0x77F407: compile_file (zend_language_scanner.l:376)
==17658==by 0x601350: phar_compile_file (phar.c:3393)
==17658==by 0x7ACF48: zend_execute_scripts (zend.c:1187)
==17658==by 0x75AA52: php_execute_script (main.c:2284)
==17658==by 0x8406D3: main (php_cli.c:1193)
==17658==
==17658== LEAK SUMMARY:
==17658==definitely lost: 232 bytes in 1 blocks
==17658==indirectly lost: 416 bytes in 6 blocks
==17658==  possibly lost: 1,720 bytes in 4 blocks
==17658==still reachable: 1,008 bytes in 7 blocks
==17658== suppressed: 0 bytes in 0 blocks
==17658== Reachable blocks (those to which a pointer was found) are not
shown.
==17658== To see them, rerun with: --leak-check=full --show-reachable=yes
==17658==
==17658== For counts of detecte

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Rasmus]

On 06/16/2011 12:42 PM, Rasmus wrote:
> On 06/16/2011 11:40 AM, Pascal COURTOIS wrote:
>> Le 16/06/2011 12:31, Rasmus a écrit :
>>> On 06/16/2011 11:03 AM, Pascal COURTOIS wrote:
  If you followed the thread you have seen the reduced test case is
 VERY short and the ONLY constructions involved are user functions and
 exceptions. FULL STOP. Not even a single addition nor a loop nor nothing.
 I can't imagine nobody uses user functions and exceptions.
>>>
>>> You might also consider that your particular case is rather unique. I
>>
>>   since decoder-...@own-hero.net could reduce the case from my original 
>> program in the conditions I stated, he could obvously detect the leaks.
> 
> I'm not saying there aren't any. There are known leaks in compile_file()
> when you throw an exception like that, so if you call a huge amount of
> these within a single request, you are going to have problems. But that
> is not something the average person hits, and again, they are all
> free'ed on request shutdown, so it isn't like it is a persistent leak.

I was bit unclear there. The cause of the leaks is the exit() in your
exception, not the exception itself.

-Rasmus

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 13:42, Rasmus a écrit :
> On 06/16/2011 11:40 AM, Pascal COURTOIS wrote:
>> Le 16/06/2011 12:31, Rasmus a écrit :
>>> On 06/16/2011 11:03 AM, Pascal COURTOIS wrote:
  If you followed the thread you have seen the reduced test case is
 VERY short and the ONLY constructions involved are user functions and
 exceptions. FULL STOP. Not even a single addition nor a loop nor nothing.
 I can't imagine nobody uses user functions and exceptions.
>>>
>>> You might also consider that your particular case is rather unique. I
>>
>>   since decoder-...@own-hero.net could reduce the case from my original 
>> program in the conditions I stated, he could obvously detect the leaks.
> 
> I'm not saying there aren't any. There are known leaks in compile_file()
> when you throw an exception like that, so if you call a huge amount of
> these within a single request,

  which is not the case. At most I will have 3 or 4 exceptions per request.

> you are going to have problems. But that
> is not something the average person hits, and again, they are all
> free'ed on request shutdown, so it isn't like it is a persistent leak.

  Ok, as said before I will summerize the facts on tuesday.

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

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Andi Gutmans]

>-Original Message-
>From: Pascal COURTOIS [mailto:pascal.court...@nouvo.com]
>Sent: Thursday, June 16, 2011 12:28 AM
>To: Lester Caine
>Cc: PHP internals
>Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
>
>Le 16/06/2011 09:19, Lester Caine a écrit :
>
>>>when you have a bug in PHP it should not ever ever crash PHP and
>>> unfortunately I encountered that case dozens of times.
>> At least on Linux is just recovers and carries on
>
> If PHP crashes, yes, it recovers but it's VERY resource and time consumming.
>If PHP corrupts some memory, it does not crash fastcgi processes but the
>next
>request(s) behave erratically.

I have some news for you. Ruby has crashes, Python has crashes, even Java has 
security issues and crashes (check out the Java bug database. It's bigger than 
ours).
Of course our goal is to reduce this as much as possible for PHP and as was 
stated here, short concise reproducible scripts do get attention. 

Re: memory models, PHP actually has a memory model that is very robust and 
prevents leaks from happening. Every memory model has its pros and cons but 
leak-free Java is a great example of where the memory model more often than not 
bites you in your tush more than you'd think (and I can say that after having 
done quite a bit of Websphere development - yuck).
 
So just help us with identifying root cause and you will see the internals@ 
group very much jumping on the issues and try to resolve them.
Andi

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Stas Malyshev]

Hi!


I'm not saying there aren't any. There are known leaks in compile_file()
when you throw an exception like that, so if you call a huge amount of
these within a single request, you are going to have problems. But that


You actually can't call huge amount of these in one request, as this 
particular leak is caused by bailing out from zend_execute_scripts, 
which causes main op array not be freed. zend_execute_scripts() is 
called only once, so you can't have this leak multiple times as far as I 
can see. Whatever caused the original problem, it's highly unlikely it 
is this leak.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Re: [PHP-DEV] Give the Language a Rest motion (fwd)

[Pascal COURTOIS]

Le 16/06/2011 18:11, Andi Gutmans a écrit :

> I have some news for you. Ruby has crashes, Python has crashes,

  Probably. any references about that ?

> even Java has security issues and crashes (check out the Java bug database. 
> It's bigger than ours).

  IMHO java is a big s**t but that's really out of topic

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