Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed
Hello, On Wed, Mar 6, 2013 at 11:31 PM, Bob Weinand bobw...@hotmail.com wrote: false. It's like unset($setValue) unset($undefined). I've clarified this in the RFC; thank you. Bob Weinand Am 06.03.2013 um 22:24 schrieb Steve Clay st...@mrclay.org: On 3/6/13 4:10 PM, Bob Weinand wrote: https://wiki.php.net/rfc/unset_bool What's the return value of unset($setValue, $undefined) ? Steve Clay -- http://www.mrclay.org/ Would it make more sense to return an array with keys the name of the variables that were unset and the result for each of them? This way one could better handle 'false' being returned. I'm not sure if it's possible or not, I didn't had the time to check out the patch. Thanks 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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On Thu, Feb 28, 2013 at 10:27 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/28/2013 11:34 AM, Anthony Ferrara wrote: Zeev, No syntax changes, so regular majority as far as I can tell. However, it does nuke several existing PECL extensions (some fatally). For example, XDebug has no compatibility with ZendOptimizer+ right now (at least that I could find, feel free to correct me if I'm wrong here). It works fine. You just have to load ZO before xdebug. If you load it the other way around bad things happen. This wrong load order currently happens if you toss it in your config file path dir and rely on the alphabetical load order which is another reason to not have this thing start with a 'z'. And some could argue that shipping with a modification that breaks known and widely relied upon (if only for development) extensions would fit into this category. Since the fix for this is trivial, I think this isn't a valid concern. -Rasmus Hello php.internals, I've read all the e-mails so far and there are valid points from both parts but it seems there's a critical thing missing. What do PHP users want? I mean, what do sysadmins, programmers and managers want from PHP 5.5? Here's my personal opinion: I work in an enterprise so... I want stability (includes bug fixes) and speed. In this order. Language features are on the third spot, at least this is the case for PHP 5.5. We'll get generators and a function for passwords and something I really don't care about :) Why? Because I won't have a chance to use them soon and by the time I'll use them PHP will get to version 5.8 most likely. So for me the fact that PHP 5.5 will be delayed a couple of months is irrelevant. We upgrade either to use better tools/frameworks or to benefit from security patches when versions are no longer maintained so unless something big appears earlier there's no point to upgrade. Don't get me wrong, those features are great, as much as those in PHP 5.4, yet history tells us that people still didn't made that step to upgrade to 5.4 yet. So if those features are not that 'something big' then what is it? A huge, out of the box, speed bump for production machines. Could this be done with APC? Most likely, that is if a stable APC were to be released same time as PHP 5.5. I really don't want to offend anyone but see what happened with 5.4 and APC. What I'm trying to say is: if O+ can be added to PHP 5.5 and made stable, and I do mean production ready which from my understanding is almost there, then why shouldn't it be done? But I'm just a single user. Maybe I'm right, maybe I'm wrong. But so are the other people who replied here so far, they are all only individuals. This is a perfect opportunity for testing out the whole: 'ask your users' thing that me and several other people were talking about. How expensive would it be, both in time and actual costs, to actually make this happen? Either setup a poll on php.net or on a third party service for one-two weeks and ask the users these simple questions (obviously they could be better, POC ahead): What do you expect from PHP 5.5? (multiple choice) - better security - better stability - better speed - more language features - other type here - all of the above Do you know what an opcode cache is? - yes - no Would you be ok if PHP 5.5 will not ship in April 2013 but in August 2013 because we want to integrate an opcode cache, a functionality, which once used could increase the speed of your applications by up to 50% or more*? - yes - no * NOTE: the speed increase is not guaranteed to be the same for all applications nor it is guaranteed. Would the fact that PHP 5.5 doesn't ship as originally planed, if the mentioned integration happens, affect your view about PHP? - yes - no What position do you have in your company? - developer - sysadmin - devops - manager - other: type here Are you in a position to influence the upgrade from your current PHP version to PHP 5.5? - yes - no Afaik every major framework has someone here, on the ML, then we have Zend and we have some other libraries and so on here as well. Imagine if all those people would link from their websites to the said poll. I think it would be a small effort from them but the responses could at least point out to what users actually want and help you in sorting this out. If I offended anyone, which I'm almost sure I did, it was not my intention, please forgive me. Thank you all for your hard work on PHP. 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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
I've read all the e-mails so far and there are valid points from both parts but it seems there's a critical thing missing. What do PHP users want? I mean, what do sysadmins, programmers and managers want from PHP 5.5? Here's my personal opinion: I work in an enterprise so... I want stability (includes bug fixes) and speed. In this order. Language features are on the third spot, at least this is the case for PHP 5.5. We'll get generators and a function for passwords and something I really don't care about :) Why? Because I won't have a chance to use them soon and by the time I'll use them PHP will get to version 5.8 most likely. So for me the fact that PHP 5.5 will be delayed a couple of months is irrelevant. We upgrade either to use better tools/frameworks or to benefit from security patches when versions are no longer maintained so unless something big appears earlier there's no point to upgrade. Don't get me wrong, those features are great, as much as those in PHP 5.4, yet history tells us that people still didn't made that step to upgrade to 5.4 yet. So if those features are not that 'something big' then what is it? A huge, out of the box, speed bump for production machines. Could this be done with APC? Most likely, that is if a stable APC were to be released same time as PHP 5.5. I really don't want to offend anyone but see what happened with 5.4 and APC. What I'm trying to say is: if O+ can be added to PHP 5.5 and made stable, and I do mean production ready which from my understanding is almost there, then why shouldn't it be done? But I'm just a single user. Maybe I'm right, maybe I'm wrong. But so are the other people who replied here so far, they are all only individuals. This is a perfect opportunity for testing out the whole: 'ask your users' thing that me and several other people were talking about. How expensive would it be, both in time and actual costs, to actually make this happen? Either setup a poll on php.net or on a third party service for one-two weeks and ask the users these simple questions (obviously they could be better, POC ahead): What do you expect from PHP 5.5? (multiple choice) - better security - better stability - better speed - more language features - other type here - all of the above Do you know what an opcode cache is? - yes - no Would you be ok if PHP 5.5 will not ship in April 2013 but in August 2013 because we want to integrate an opcode cache, a functionality, which once used could increase the speed of your applications by up to 50% or more*? - yes - no * NOTE: the speed increase is not guaranteed to be the same for all applications nor it is guaranteed. Would the fact that PHP 5.5 doesn't ship as originally planed, if the mentioned integration happens, affect your view about PHP? - yes - no What position do you have in your company? - developer - sysadmin - devops - manager - other: type here Are you in a position to influence the upgrade from your current PHP version to PHP 5.5? - yes - no Afaik every major framework has someone here, on the ML, then we have Zend and we have some other libraries and so on here as well. Imagine if all those people would link from their websites to the said poll. I think it would be a small effort from them but the responses could at least point out to what users actually want and help you in sorting this out. If I offended anyone, which I'm almost sure I did, it was not my intention, please forgive me. Thank you all for your hard work on PHP. And I've forgot the most important question: Would you skip PHP 5.4 migration if the opcode caching were to be included by default in PHP 5.5? - yes - no 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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On Thu, Feb 28, 2013 at 11:37 PM, Levi Morrison morrison.l...@gmail.com wrote: A huge, out of the box, speed bump for production machines. For some applications PHP 5.4 was a huge speed bump out of the box . . . Would you run PHP against 10k+ req/s in production without opcode caching? On how many machines without / with? 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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On Thu, Feb 28, 2013 at 11:47 PM, Anthony Ferrara ircmax...@gmail.com wrote: Florin Would you run PHP against 10k+ req/s in production without opcode caching? On how many machines without / with? I'm not sure about your stack, but every stack I've seen at that high of a load is built very custom for the problem at hand. And it isn't typically upgraded across minor versions (in fact, it's typically only upgraded for security). At least that's my experience everywhere I've seen that big of a farm... And when it is upgraded, it's usually a very coordinated effort that takes a LOT of planning and has a lot of moving parts... And to be fair, how many installs are there that get 10k req/s? A few hundred? That's not the kind of system we should be targeting when discussing a language feature/change. Sure it's sexy, but it represents less than 1% of the install base of PHP (much less, prob on the order of 0.01%). So while I wouldn't write them off (far from it), justifying a change because it matters to that scale is like justifying ejection seats in cars because hitting a wall at 200mph on a race track can kill you... Anthony and Levi, True but could we please get back to the whole mail and actually see what the users want? I would vote in the RFC if would be allowed to do so and I think I've explained my perspective really well and the fact that I'm just one of the hundred of thousands of PHP users. I'm part of a very small group of people who have these problems, I agree, but what I'm proposing should help out instead of just assuming things. The point is that this is yet another: we should this but that but then and what if ... that could be solved by just asking the users and taking that into account. I could bet that people could care less about a stable release cycle when things like this are at stake for certain versions. Also, as a mention, I think that the current release every year target is highly unrealistic unless you want to fragment the market the same way that Google does it with Android. And look at the problems they have with the adoption. If they can't serve as an example, I don't know how can. Especially with PHP 5.4 experience. Are you willing to bet that PHP 5.5 will do any better? 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] RFC Autoboxing Draft
Hello,
See the reply inline:
On Mon, Feb 25, 2013 at 3:43 PM, Nils Andre nilsan...@gmail.com wrote:
Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
the list at first. There has been ongoing discussion about new APIs and so
fort, so this is a suggestion for language cleanup by Autoboxing. I'd
really appreciate comments.
Follow the steps described here in order to get RFC karma and everything
should be fine: https://wiki.php.net/rfc/howto :)
== Introduction ==
This RFC tries to approach the need for Autoboxing in PHP, or, to make
primitive types behave as if they were objects when being used or accessed
in an objectional fashion. Autoboxing can be discussed from various
perspectives, which is far beyond the scope of this document, which much
more addresses the fact that the language of PHP must be cleaned up in
order to grow more in terms of maturity and hence, in user accpetance.
== Autoboxing in brief ==
Autoboxing is that we can use primitive types, like integers, strings,
booleans and array as if they were objects, but without being constructed
as objects themselves.
I'm not very comfortable with the autoboxing of --everything--. Could you please
detail why autoboxing anything that's not array or string would be
useful? I like
the idea of autoboxing for strings / arrays, where the most problems related
to parameters order would be solved but for the other types, as a developer
I can't see it.
Autoboxing is widely discussed, and somehow a must-have in OOP as a
consequence to having primitive types (for the sake of performance and
memory overhead) but keeping the language OOP-consistent.
== Why PHP needs it ==
PHP needs autoboxing as a means to restructure the language and make it
more predictable. One big flaw of today's PHP is, that it is unstructured
and chaotic with its builtin functions, as, for example, those dealing with
strings. Not going too much into details here, many programmes always have
to look up the function definition because very similar functions have
their parameters in different orders or simply don't act in a predictive,
well-structured manner. This article is a good read to sum it up:
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
The problem derives from the fact that PHP has not been designed top-down,
but has been developed the bottom-up way over many years: As of today, the
language offers features other languages don't have, but struggles with
it's buried bodies from the past (mainly because compatibility had and
still has to be kept.)
By _adding autoboxing_ for all primitive types (Booleans, Strings,
Integers, Arrays), we would clean up the language in a very consistent
manner, but still retain backwards compatibility.
== How it could be implemented ==
We would not need much programming, because we simply map the new autoboxed
notation to the old code. We suggest the new notation to reproduce the Java
notation and parameter sequence closely, because it is pretty
straightforward and consistent (see, for example, the Javadocs on
java.lang.String).
== Syntax ==
The mapping is very straigtforward. Consider this:
$a = This is a string;
$b = $a-toUpperCase()-- $b = ucase($a)
$b = $a-substring(0,4) -- $b = substr($a, 0, 4)
It would also allow many brilliant constructs like the following
if ($b-startsWith(This)) { ... }
in contrast to
if (substr($b,0,4) == This) { ... }
Notice that the latter is error-prone, because if the condition changes one
would always have to match the string on the right handside to the length
of it on the left.
This should be done in a transparent manner imho. The current substr
function should be mapped to String::substr() as well.
I'd recommend you play a bit with this: https://github.com/nikic/scalar_objects
and come up with some examples on how the classes would look like
before going forward with this proposal.
== Compatibility ==
The old notation could be switched on/off at any time.
The old notation would be switched on by default until, say, PHP 6, and can
then be enabled/disabled by either a compile flag, INI setting or some use
\PHP5\*; or something on top of a PHP file, which then makes the old
notation available to any code that follows/any file that is included
afterwards. As a consequence, \PHP5 will be the namespace comprising all
old/compatibility stuff.
IIRC disabling functionality via ini settings isn't a desired thing.
As for namespaces
I think it's a bad idea. Currently everything in PHP is global, not
namespace and
this introduces a new layer for programmers to learn of.
== Advantages ==
- Cleanup of the language
- Consistency and predictability improved a lot (also in constrast to
possible userland classes - which would then all be slightly different)
- No lacking backwards compatibility
- Easier learning for new PHP programmers (beginners to PHP would be much
more pointed to learning OOP
Re: [PHP-DEV] PHP User Survey
On Fri, Feb 22, 2013 at 8:40 PM, Florin Razvan Patan florinpa...@gmail.com wrote: On Thu, Feb 21, 2013 at 9:24 PM, Christopher Jones christopher.jo...@oracle.com wrote: On 02/21/2013 03:02 AM, Florian Anderiasch wrote: On 02/21/2013 08:14 AM, Pierre Joye wrote: I do not have a single doubt. Why? Surveys are one of many ways to get feedback. They have no contracting values but give us some numbers about one rfc or another. That may help us to focus on one feature instead of another if we see a large number of users looking forward to it. You'll never get perfect results, but I prefer results at all over none :) There have been a lot of those for other languages: - http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/ - http://survey.perlfoundation.org/ - http://survey.hamptoncatlin.com/ For the mail archives, there are also these (more focused) reports: http://static.zend.com/topics/zend-developer-pulse-survey-report-Q2-2012-0612-EN.pdf http://downloads.zend.com/guides/whitepapers/State_of_PHP_in_the_Enterprise_061212.pdf Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hello, I see that people would rather agree with a RFC on polls on the website so I think we should rather get a RFC going and take it from there. I'll gladly make it if needed so just let me know. Also, maybe the conference organizers could help the PHP community by having surveys at the conference they are organizing and provide the feedback on their website. What do you think? Best regards. Florin Patan https://github.com/dlsniper Hello, I've added the following RFC to allow discussion on it: https://wiki.php.net/rfc/site_voting_poll If there's a need for a patch before proceeding with the next step of this let me know. 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] PHP User Survey
On Thu, Feb 21, 2013 at 9:24 PM, Christopher Jones christopher.jo...@oracle.com wrote: On 02/21/2013 03:02 AM, Florian Anderiasch wrote: On 02/21/2013 08:14 AM, Pierre Joye wrote: I do not have a single doubt. Why? Surveys are one of many ways to get feedback. They have no contracting values but give us some numbers about one rfc or another. That may help us to focus on one feature instead of another if we see a large number of users looking forward to it. You'll never get perfect results, but I prefer results at all over none :) There have been a lot of those for other languages: - http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/ - http://survey.perlfoundation.org/ - http://survey.hamptoncatlin.com/ For the mail archives, there are also these (more focused) reports: http://static.zend.com/topics/zend-developer-pulse-survey-report-Q2-2012-0612-EN.pdf http://downloads.zend.com/guides/whitepapers/State_of_PHP_in_the_Enterprise_061212.pdf Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hello, I see that people would rather agree with a RFC on polls on the website so I think we should rather get a RFC going and take it from there. I'll gladly make it if needed so just let me know. Also, maybe the conference organizers could help the PHP community by having surveys at the conference they are organizing and provide the feedback on their website. What do you think? 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)
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 z...@zend.com 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 days events.
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Hello, On Thu, Feb 21, 2013 at 5:30 PM, Rasmus Lerdorf ras...@lerdorf.com 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] [RFC] Allow trailing comma in function call argument lists
Hello,
On Tue, Feb 19, 2013 at 2:06 PM, Sara Golemon poll...@php.net wrote:
Opening RFC to allow trailing comma in function call argument lists
https://wiki.php.net/rfc/trailing-comma-function-args
As a person who deals with code reviews from many programmers
each day, I'd have to say this would be confusing. I do agree that
it helps consistency but by far it implies many things that are really
not what they seem.
For example, I would expect that if I have:
function A($b, $c = 'd') {}
when I see A($b, ) to have no syntax errors but rather $c defaulted to
the value in the function signature, which is not implied nor assumed
by the RFC but it would be by the one reading a function.
Then when I have
function A($b, $c = 'd', $e) {}
to be able to have A($b, , $e) which again this RFC doesn't specify
that it allows but leads to confusion.
As for the argument about the VCS, I really don't see an issue with
the current way of thing. Some people don't use the comma at the
end of the arrays and it doesn't mean that they all should.
So from my point of view, this adds more ambiguity to the language
and the problem it solves is very small.
Best regards,
Florin
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] PHP 6 : a new API ?
Hello, On Wed, Feb 20, 2013 at 9:22 AM, Klaus Ufo klaus...@yahoo.fr wrote: Hi there ! We all know that the current PHP API has flaws. Maybe we could use namespaces to build a new coherent PHP API ? Like : - \arr - \num - \str and so on. Advantages : - no more global functions I actually like global functions even if most of the time I spend is in OO code. I don't want / need to have simple scripts / crons that are suddenly more complex to manage just because I can't have them. - separation of concerns While I understand the needs to be pure about things, I do think that there's such a thing as too pure. Does the current way of things break something? - backward compatibility This would rather be a backward incompatibility if I understand this correctly. - work can be done progressively - easy to add user-defined functions (using php namespaces) I have no troubles in having my defined functions up and running as they are now. The fact that they are always in the global scope makes things much simpler for me when I want to do simple things. - we could provide a \str\utf8 namespace Wasn't UTF8 a major pita and abandoned in favor of better things for the moment? This is just an idea. I don't know what is your vision for a next PHP 6. KH My vision for the PHP 6 is rather different that yours and if you want, you can read about it here: http://florinpatan.ro/2013/02/11/next-big-thing-in-php/ (sorry if I'm not allowed to share such links here). And as Michael Shadle said, I'd rather have things like consistent parameters order or named parameters or both rather that namespacing functions like this. 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] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
Sandy,
On Wed, Feb 20, 2013 at 11:59 AM, Sanford Whiteman
swhitemanlistens-softw...@cypressintegrated.com wrote:
Classes always should be declared with class keyword, because there could
be ambiguity whether it's class, interface or trait.
If only inner classes are allowed in a given PHP version, there's no
ambiguity about whether something{} just inside a a class is an
inner class.
That's the justification for removing function just inside classes,
isn't it? That it's not ambiguous because the only thing as of PHP.now
that can take the form sometype somevisibility something(){} is a
function?
Well, if in PHP.later, the only thing that takes the form sometype
something{} is an inner class, then leaving off the sometype there
is also unambiguous (but also similarly gratuitous).
And if in PHP.later.still you have inner interfaces, then the
unmodified one still defaults to inner class and only a literal
interface something{} is an inner intf.
(I'm attempting a RAA argument but maybe failing)
-- Sandy | FigureOne Support Team
I think you've abstracted this one way too much.
For me right now all I see is a useless keyword in a class. We don't
have 'visbilitytype var/property $varName' right now but you are
comfortable with them knowing that they are just properties of the
class.
If I were to be on this road I could in fact argue that currently we have
a lack of consistency between class methods and properties. You can
have a look on this image if you want an example:
http://i.imgur.com/Q0ZOZns.png
For the part where public is optional, I think that most frameworks
and practices they promote and users actually do type the keyword
and have it there for the sake of consistency. It might not be the case
for now, but I think that it would rather be useful to enforce the visibility
types rather that the 'function' keyword.
As for classes/interfaces/traits and so on, if they are ever added in PHP
to be declared inside classes and so on then I see no issues with this.
A class/interface or a trait keyword would still be needed to make the
difference between a them imho.
Grepping for sources is like a daily operation and by using IDEs like
Netbeans/Eclipse/PHPStorm one has the ability to just search for a
symbol directly, regardless if you can click of function name or not.
No voting karma here as well but I do tons of code reviews and this is
just my opinion, you know, from the userland.
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] PHP User Survey
Hi Paul, On Wed, Feb 20, 2013 at 10:00 PM, Paul Reinheimer preinhei...@gmail.com wrote: Hi All, My apologies for the intrusion, I'll keep this brief. In many discussions over the past few months there has been talk about what the community at large needs. Pierre said just earlier today: 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. The other point that comes up is the difficulty in reaching a large portion of the community. They don't come to conferences, they don't sit on this list, they don't go to user groups. They work with PHP for months or years, but the rest of the community doesn't even know who they are. I believe Rasmus has mentioned this on a few occasions. So my suggestion is simple, let's ask them: What they want, What they need, how they installed PHP (source, rpm, deb, provided by hosting provider, Zend Server), etc. Let's create a survey, and link to it prominently on php.net. I considered just writing a survey myself, but even if everyone I knew tweeted it I'd still lack the reach to hit those outside the traditional community. While this is clearly not a suggestion to change PHP, i'll write this up in RFC format if there's interest. Should give people an opportunity to discuss questions and such. thanks for your time paul -- Paul Reinheimer Thank you for championing this. I've been promoting this kind of feedback for a while now. Just like the discussion I've had earlier on the IRC channel, I do believe that when proposals are made/are at a point where the internals don't agree with which solution is better and it should affect the community at large, it would be better to just ask the community and see what they want/agree on. The issue would be that in some cases one side would lose but the same thing happens when the debate is done here, on the mailing list, and a solution doesn't satisfy some people and ends up being the standard for the whole community. These votes shouldn't be seen as a must but should serve more as a guideline. As for the problems raised by Kris, I think that a simple system based on the e-mail address of the voter with some prior confirmation / pending approval, like for the mailing lists, should be enough to grant the right to vote or not. Even if some people were to have multiple accounts, I don't think they'd go to the trouble of spawning a very large number of e-mail addresses just to see their favorite option accepted. I'd be more that happy to provide any help possible for the RFC as well as the survey / surveys themselves. 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] [RFC] Short syntax for anonymous functions
Hello, On Tue, Feb 19, 2013 at 2:57 PM, Marcello Duarte mdua...@inviqa.com wrote: Inspired by Sara, here is another RFC, I finally got around to draft: https://wiki.php.net/rfc/short-syntax-for-anonymous-function Please feedback, -- Marcello Duarte I really don't like syntax for this. It makes it hard to follow. Removing a couple of characters while making the syntax harder to follow isn't a good thing imho. Also it's a BC break, like Patrick mentioned. Have a nice day, Florin 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] [RFC] Short syntax for anonymous functions
Hello,
On Tue, Feb 19, 2013 at 6:09 PM, Levi Morrison morrison.l...@gmail.com wrote:
There's already been an overwhelming negative reaction to this
particular proposed syntax so I won't belabor the point much. In
short, this is too similar to block statements and does have BC
issues.
--
IF (and I stress if) we add a a shorter anonymous function syntax I'd
like it to be geared towards one-liners because that's where the
current syntax feels really verbose, especially when you close over
other variables:
function ($n) use ($m) { return $m * $n; }
Versus one potential option:
($value) |$m| = $m * $n;
This syntax is short and expressive at the expense of clarity.
Basically all short-syntax has that trade-off, so I am personally fine
with it. The only other potential problem I see is parsing it; someone
more familiar with PHP's parser would have to verify whether that
would be a problem.
I think that before we establish a syntax for this we should see if there's
a real need for this feature, and after that, get a syntax to implement the
feature.
Say we agree on the syntax above
($n) |$m| = $m * $n;
What happens when my one liner function needs to do one more operation
like checking the value of $n before multiplication?
I'd rather see a proposal to drop the 'function' keyword from the classes
methods and only leave the visibility scope and method name, but for
anonymous functions like this one I'd rather keep the 'function' keyword in
order to have better visibility when I'm doing a code review/scan new code
in a library.
What do you think?
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] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Thank you for this great initiative! As a user, I could definitely wait for 2-3 more months and get a good implementation/integration of this rather that have to wait for at least one year. I think it would also be nice if this could come as default enabled since this way people would be able to notice the advantages of having it enabled. Or you can run a survey on php.net to see what are the options. I do have one thing to ask you about this. If we do wait 2 months, will the underlaying changes be able to integrate easy with APC/XCache/eAccelerator/others? Opcodes are a must for large traffic websites like those I'm working on right now, so we clearly want to have such a thing installed on our servers as soon as we install a new PHP version. But if including O+ will mean that APC gets delayed 6+ months (see PHP 5.4) it would be a show stopper for us upgrading to PHP 5.5. Our upgrade process is like this: be at least one year on market to iron out major/obvious bugs. If APC gets on the market 6 months after PHP 5.5 only because of this then we'll be near PHP 5.6 by then. And we can't just change from APC to others as we'll need to test them as well as see which other use data caching like APC has. It would make sense to actually see how the whole ZE can be improved so that it makes life of opcode cachers easier and then ship O+ bundled with a PHP version that has better support for them out of the box if I were to choose. Best regards, Florin Florin Patan https://github.com/dlsniper http://www.zend.com/en/yellow-pages#show-ClientCandidateID=ZEND013894 On Tue, Jan 29, 2013 at 10:03 AM, Zeev Suraski z...@zend.com wrote: All, Following the discussion at the end of last week, I prepared a draft RFC for the inclusion of Optimizer+ in PHP. In parallel we’re in the process of prepping the source code for independent public consumption, which I hope we can be done with by the end of next week, hopefully sooner. https://wiki.php.net/rfc/optimizerplus Comments welcome! Zeev
Re: [PHP-DEV] Voting periods
To Zeev and the rest of internals, I know this will be a long e-mail but I'm not a guy who goes to conferences (I don't have money for that), I've been into seven companies until now, each with various use cases for PHP and I'm trying to contribute to some open source projects from PHP scene. You say that most of the users don't speak so I'll try to speak as my previous attempts where ignored... Let's start with the broken image about PHP 5.4 and adoption rate. I'm not sure where, but today was given the argument of not doing userland BC breaks while in 5.x branch, yet you just did that for 5.4 and now you use it as a reference for adoption rate. PHP 5.4 adoption rate is the best indicator but not for the number of people who like new features but rather for the number of people who can afford to run without APC or have clean code. Why do I say that? Consider this: since there's no common API for XCache/ Zend (forgot it's name) and other opcode accelerators/cachers I can't upgrade to use another alternative. And who's to say they don't suffer from their own bugs? Do you know what happens when I ask my NOC guys to install some new extension? Things like: is it stable? Will it crash and burn my very sensitive yet stable servers? Is it faster/slower that the alternatives? Testing the changes alone will make my company waste more money that having me coming up with clever ways to provide workarounds or design things for them so that upgrades like this can be avoided. PHP 5.4 broke yet another thing. You've removed usage of register_globals. That's a great thing but you've locked out many shared hosts as they can't upgrade without making the customers upgrade their code first. That might not even be possible for some people. I happen to maintain such a badly written application, but it's working like that since 2002 and I can't believe that my employer will ask me to upgrade it at some point to make it compatible with 5.4+. But I can do that, can you say the same thing for the rest of the world? I'd love to use traits in projects, there's great usage for them, especially when you go and write OOP code, the proper way... Can I do it? Sure, I have a VPS which allows me to experiment but that's about it. Thank God, you'll stop supporting 5.3 next year which is actually the reason for why I'll be porting the application to 5.4, if possible, if not, 5.3 then 5.4 another time ;) Why do I need those new features in the first place? Just because I might be experimented enough in order to understand the benefits from having them and how to use them to their true potential. I don't understand feature X? Well ok, I need to read more about it. But some smarter guys that make frameworks, ORMs, CMSs and other large adopted and used PHP applications understand them, want them need them to provide better code for people to use, learn from and write. You think that majority of people write PHP in a professional way? Could very well be true, in your countries, in mine, the focus is on getting things done, nice if possible, if not, don't sacrifice the business time to write nice code. I still manage to write nice code under these conditions because I want to do more in life that be a simple code monkey. Every monkey can write code, not every monkey can think beyond the next echo they'll write. Then there's Wordpress. I'm still waiting for a day when the code base from Wordpress won't be given as a negative example but Wordpress runs on a biiig number of sites. Do you really really want the opinion of users about a certain RFC? Put up a pool on the website and promote it on the frontpage, Zend mailing list, forums and so on. Announce it at least one week before it runs and run it for two weeks. That should prove accurate enough from people interested in the language itself. Those who are not interested shouldn't count anyway. How that RFC will be implemented is obviously another thing, but it should be contained by internals not subject to public voting. But the core needs more contributors. Yes, I could be one. Why I'm not a contributor to the core? Well here's a couple of interesting things: - I haven't learned/used C until now, I've learned Pascal in highschool, then Java at university and I've done programming in PHP for seven years now. Not once I've needed, wanted to learn C (until today that is); - my time outside of work is limited and have to split it up between many things (like most of you) - I need to learn more PHP, more design patterns, more systems architecture, more anything that's not related to C but rather systems, patterns and anything else that I can so that I can write better software for my employer, keep up with new people coming after me, provide solutions that save me code, my employer money and is easy to understand by people that will maintain after I'll leave my job; - PHP is written in C not in PHP which means that unlike people that write C all day, for me C is another way
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
Hello, I'm not sure if it could be considered as a feature but what about these RFCs: https://wiki.php.net/rfc/error-optimizations https://wiki.php.net/rfc/grisu3-strtod Some of them have been opened for some time now. Also, wouldn't a cleanup of the current RFC listed for PHP help out in the process? I'm not sure what's the process for this, but it should be done at some point imho. Best regards. Florin Patan https://github.com/dlsniper On Thu, Jan 24, 2013 at 11:39 PM, David Soria Parra d...@php.net wrote: Hi Internals, as you might have read in the 5.5.0alpha4 announcments, we are moving forward with 5.5.0. We are already a bit late on the schedule and we want to begin the beta cycle in 14 days and concentrate on QA for the 5.5.0 release from now on. This includes a feature freeze. No new features should be comitted to the repository once we tagged the first beta on Feb 7. All outstanding features will have to wait for 5.6.0 in a year unless there is a really good reason for an exception. Feature Freeze is on Feb 7, 2013. Regards, Julien and David -- 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] I think that Function naming inconsistency bug deservers more attention
Hi, Everyone here forgets that there's a little certification run by some guys named Zend that factor in some of these things as well. That's the point of not having consistency? Checking if some have better memory that others? Also, I suppose that everyone can afford to look up things on the PHP manual when doing debugging on some crashed remote service via CLI only access. Now, on a nicer tone. Consistency across function name/parameters would help out both new people that learn the language as well as leave out one point when compared to the other languages. Sure, there's no point in changing things just for the sake of it but I don't get it why this couldn't be a viable option for PHP 6 for example, which is a major release. It would definitely help out new users and get some bonus points while doing so in order to close the mouth of those arguing that PHP is so inconsistent in naming things. Phil Sturgeon had a nice idea on his blog, http://philsturgeon.co.uk/blog/2013/01/php-6-pissing-in-the-wind which I think could very well apply to PHP and maybe something like this could be done by someone with less C/PHP internals knowledge that some other features. If that's the case and all we need is someone to do the changes, then I could level up my C knowledge and help out if no one else is willing to do it. I'd dislike for it to be rejected with reasons like: - but it doesn't bring anything new; - it doesn't help us with anything; - it doesn't solve real problems; - the current functions reflect the underlying functions used. I've been a PHP user (developer) for a couple of years now and I really don't care what's the parameter order for the functions that PHP use to help me out getting my job done; - perfection ain't good. Best regards. Florin Patan https://github.com/dlsniper On Sat, Jan 26, 2013 at 7:13 PM, Kalle Sommer Nielsen ka...@php.net wrote: Hi 2013/1/25 Damian Tylczyński turneli...@gmail.com: I've seen discussion on reddit http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/ There is one really clean solution to this problem for the consistency Guys that tend to complain about PHP endlessly; write the aliases in PHP that can be included, which can be considered just like using one of the frameworks thats filled with functions, it can be written quite fast and you can even use auto_prepend_file to include it in all scripts. As said in countless mails above, there is no gain for breaking BC due to perfection. -- regards, Kalle Sommer Nielsen ka...@php.net -- 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] PHP is not ...
Hi Arvids, This is exactly what I've stated yesterday here, you can read it at http://news.php.net/php.internals/64820 but I've yet to receive an answer for it. The problem is that someone will actually need to implement the whole thing again, in C, again, and it's going to be painful (again). I can only say that I'm really sorry that I don't know C in order to be able to contribute. This is indeed a sensible subject and I wouldn't want to be hated by the current developers / contributors but like I've said, at some point it must be addressed. Best regards, Florin Florin Patan / @dlsniper On Fri, Jan 11, 2013 at 2:06 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: I have to agree with Lester. It seems that there is a conspiracy to push annotations into PHP :D No, really, it's like goons decided that PHP needs annotations no matter what and just flooded the mailing list. I think: The line must be drawn here, this far, no further! © Star Trek Before adding more major stuff we should cope with what was already added and get it into shape. Traits are getting a rewrite for the 5.5 release and APC can't catch up because of the traits. This is the first big problem that needs to be solved. Unicode is the second big problem. As far as I know there was some work done on mb_string like enabling func_overload by default, but there are functions missing that are in standard string extension. Just continue on course and get more people involved. Maybe make a roadmap and try to stick with it. 3rd problem is PDO. It lags behind for years and as far as I know from the words of Perrie, no one is willing to touch it and it's a mess. I will not even start on the fact that it lacks tons of functionality and is extremely limiting when you start to do some serious stuff. The fact that virtually every framework bases it's DB layer on the PDO makes it even worse - a fast comparison between PDO and mysqli shows how limiting the PDO is. Just an example, mysqli has mysqli_ping. You can't do that in PDO, so I had to send a query SELECT NOW() every 10-15 seconds to the MySQL server to keep the connection alive. Because when PDO looses connection, it gives you an error and you can't just reconnect and continue. Oh, the PHP function API issue, like array vs string. Huge amount of improvements can be done here. This is just what gets into mind and I stumble upon regularly. Maybe these problems should be addressed first before adding more stuff? Arvids. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision
This could be very well be off-topic but I think it is something that someone has to say it at some point. Don't worry, there's a vision in there, near the end of this, please just have the patience of reading this as a part rant, part wish :) You all speak about new things, better userland code, gaining new features, functionalities, getting a vision but you never speak about the core. There's a clear need for a change in the core but new features are demanded every day... Solving the core should be done with a major BC break after 5.5 and it should improve all the things that need to do be improved while preparing the architecture for future changes/additions. I think that Symfony2 should be a great example of this being a good approach in terms of produced results. If you look at the code it will provide both the cleanness and the flexibility needed to do great things with it yet it allows it so be simple to pick up and learned by new devs. Maybe other projects, including PHP, should take this lesson and see how they can make themselves better even if in the process they'll break all user space. For PHP strictly speaking now, I think that after 5.5 there should be a pause of two-three months for devs, get a holiday or just relax, then, sit with the community at a couple of meetings and talk about how PHP 6, 6.1, 6.2 and so on could/should look like. I'm not saying it's going to be an easy task, nor a pleasant one, but this should be done sooner that later as it's bound to happen at some point imho. While we might not get cool new things like annotations, named parameters or anything else that we, the users of PHP would like, we could get: - better internals which help adding those missing features faster; - make APC easier to maintain if the parser/compiler are easier to interact with; - get consistency in the whole haystack/needle problem :) - possibly get a better extension system so that C extensions are easier to write/maintain; - those missing things faster / easier to implement in PECL; - maybe more :) Redoing PHPs internals would help also getting a vision of the language, that suddenly every one cries about, while getting cleaner code for the core and help to increase the general numbers of core contributors for it. With such a large user base I still find it extremely surprising that php-core is maybe a dozen people or so while projects like Symfony/Zend Framework/Typo3/etc have hundreds of contributors. Yes! We 'need' new cool stuff in PHP, that maybe will be forgotten in two-three years or not, we find new ways to make the userland code more easy to write, operate, read and above all faster! But you can't build a 70 story skyscraper on top of a foundation that's meant to support a five story building. If you are going to ask the core devs to accept/do something that you deem cool, why not thinking about doing the things better all-around first, then add the coolness factor later? And yes, annotations are cool but it's' by far a --must-- have or something that gets in the way of developing new ideas to the point where they just can't exist (as proven by Doctrine Common). Have a nice day. Florin Patan / @dlsniper On Thu, Jan 10, 2013 at 3:29 PM, Anthony Ferrara ircmax...@gmail.com wrote: Rasmus, Rasmus: A general purpose scripting language with a focus on web development You: being simple and practical and focused on the web While they both have web in them, they provide very different goals and metrics with which to gauge contributions by. And that's the entire point of my call for a single, consistent and official vision... They don't seem different to me, and the first one is the documented statement that has been the first thing people see on http://php.net for years and years. You can add simple and practical to mine or add general purpose to the Stas one and it doesn't conflict in any way. There's a difference between a byline and a vision. But even deeper, the vision that you wrote widens the scope of PHP development into basically all possible directions, as long as Web Development is a focus. Stas's vision on the other hand narrows the scope quite significantly by focusing on simple and practical implementations. Here's an example of the difference. Let's say that an RFC came out to introducelist comprehentions PHP. According to your vision, that's completely on the table and is welcome. But Stas's stated vision would counter that because it's not simple. And Stas's stated vision leads to things like this: http://news.ycombinator.com/item?id=5034365 It is trivial to misinterpret (or perhaps not so mis) it as we can't do anything complex, because think of the new people. What I'm proposing here is a stated vision that clarifies and sets a reasonably narrow vision for what development should do. I'm not saying it needs to be a 100% we can do this but never that,
[PHP-DEV] [RFC] Implement a LoggerInterface to PHP
Hello, After a talk on the Symfony framework here: https://github.com/symfony/symfony/issues/5911 Long story short, the point that @Seldaek suggestion to have a common interface for loggers actually makes sense and the best way to have it would be to have PHP include it by default. I'm not sure exactly what amount of work this implies, nor my C skills are existent, but with PHP having such an interface available it would help standardize things in the PHP world. Also, I'm not sure if this could be backported into existing PHP 5.3 or PHP 5.4 versions but this would make sense to consider it for PHP 5.5. What do you guys think? Could this be considered to be included in PHP? Thank you for your time. Best regards, Florin Florin Patan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
