Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
On Thu, Jun 2, 2011 at 12:09 AM, Sean Coates s...@seancoates.com wrote: Now, the only reason I would personally support the array shortcut is if it was an implementation of JSON. I know that's not on the table here I don't think anything is officially off the table, unless we forego discussion. My application is largely JSON-powered. We pass data from back- to front-end via JSON, we interact with MongoDB via the extension (which is an altered JSON-like protocol (arrays instead of objects), but would be a lot more fluent with actual objects—they're just too hard to make in current PHP), and we interface with ElasticSearch. The paste I linked earlier is our primary ElasticSearch query. The benefits of first-class JSON are important and wide-reaching; especially when interacting with systems like the ones I've mentioned. There's a huge amount of value in being able to copy JSON out of PHP and into e.g. CURL to make a query to ElasticSearch without worrying that I've accidentally nested one level too deep or shallow, or accidentally mistranslating my arrays into JSON. This is not about saving five characters every time I type array(), it's about making my systems all work together in a way that's a little less abstracted, and a lot less prone to error. the whole patch and RFC was about saving a few types of characters. so I think that some of the make JSON first class citizen in PHP supporters should open a separate RFC with pros and cons, what BC break can that cause, etc. before we can vote on that. but I think that this patch and RFC (maybe with the removal of ':', so we only support '=') could and should be voted on. but if we mix the two idea, we will lose both, at least this is what happened many times on this list. so please, update the current RFC if needed, and maybe we should restart the vote. don't make this into and endless bikeshedding with continuously throwing loosely related half-baked ideas on top of the discussion. thanks. Tyrael
Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
On Jun 1, 2011, at 7:35 AM, Derick Rethans wrote: But only if you keep it consistent, PHP has always been using = for key/val association, I don't see any reason to suddenly provide key: val, unless what you want is to confuse people. Yes, definitely = vs. : in any case. +1 to this. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
2011/6/2 Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com
I don't think anyone cares about JSON for the sake of being perfect
JSON, I didn't intend to give that impression.
Then you should stop saying pure JSON and true JSON constantly!
I'm only hoping for something that generally works on par with all
the other JSON parsers in the world.
OK, that trashes your example, where values were set based on the
result of a PHP function. There is no par for JSON parsers running
methods _at creation time_, within the server (author) context.
Setting vars to the return value of a function is something we take
for granted in real languages, but it cannot happen within what a
knowledgeable person would call JSON.
Yes, JSON is a very specific encoding, but when a developer writes
something jsony, what they mean is an object/array with the
following structure/values, because that is what the encoding
really represents.
Not Javascript developers. Maybe jQiddies think that
{'$gt': strtotime('-1 day')}
is JSONy more than it is JS objecty?
This is like starting from Wouldn't inline CSVs be great for creating
arrays? and drifting to I mean, not like with that comma-escaping
stuff, and, uh, newlines would be allowed in the middle of a record,
and you'd have to allow create-time interpolation of function calls.
You know, CSVy!
Only thing I might generously refer to as being JSONy, while
provably not being valid JSON, is a string that conforms in every way
_except_ for using single quotes -- everywhere that doubles are
required -- instead of using doubles. Anything else is someone's
mangled JankySON or just not JSON.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-1 to the RFC.
+1 to = against : if the array short syntax it's finally implemented.
I, being a lazy programmer, don't want anymore new syntax to do the same
thing. I don't care if it a) saves me houndred of kaystrokes in the
definition of arrays, or if b) it's more familiar with
_put_your_favorite_syntax_here_ because:
a) I prefer the simple way of _this_ is done _this_ way against _this_ is
done _this_ way or _this_another_ way or _this_yet_another_ way.
b) When another new fancy tendency of encoding appear I don't want to see it
in the core, because another one will appear in the future and then we will
be in the same point, stacking stuff forever or talking about deprecating
the old and breaking BC.
My point is: I'm for implementing something that can't be done currently in
PHP, but against for implementing another way of doing the same.
RE: [PHP-DEV] RFC: Short syntax for Arrays (redux)
-Original Message- From: Michael Shadle [mailto:mike...@gmail.com] Sent: 01 June 2011 21:37 On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye pierre@gmail.com wrote: I modified the vote page, pls move your votes to the desired syntax (or global -1) This is a good idea to group things like this. Back on the soapbox. All of this is just to reduce typing array (5 characters) before things? Not here. For me, the shorter syntax is simply an order of magnitude more readable. I really don't care how much typing is involved -- if I were really that fussed, I'd simply set my editor to expand a nice short abbreviation (such as ar, maybe) into array(). In fact, I might go do that right now, now that I've thought of it Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507 City Campus, Portland Way, LEEDS, LS1 3HE, United Kingdom E: m.f...@leedsmet.ac.uk T: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
Re: [PHP-DEV] Final version, RFC release process
On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind peter.e.l...@gmail.com wrote: Sorry for jumping into the thread, but I couldn't help noting that you seem confused about the distro suggestion. I think Ubuntu was the example, and there's nothing random at all about their release process. There are fixed timelines and life cycles in Ubuntu - having less branches does not in any way stop them from having a fixed release process and schedule. It is about random release being chosen as LTS. For many users, it will preventing migration until a given feature is part of a LTS release. Our proposal to have fixed life time and release cycles does not have this random effect and each x.y release is equally supported for the same duration. The amount of branches can be reduced easily and even if we may have many at one point, it will be only about sec fixes, that's really not a problem (a bit of automated tasked will help here too). 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] RFC: Short syntax for Arrays (redux)
On Thu, Jun 02, 2011 at 08:21:37AM +, Ford, Mike wrote: Back on the soapbox. All of this is just to reduce typing array (5 characters) before things? Not here. For me, the shorter syntax is simply an order of magnitude more readable. I really don't care how much typing is involved +1 -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
On 02/06/11 17:23, Pierre Joye wrote: On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind peter.e.l...@gmail.com wrote: Sorry for jumping into the thread, but I couldn't help noting that you seem confused about the distro suggestion. I think Ubuntu was the example, and there's nothing random at all about their release process. There are fixed timelines and life cycles in Ubuntu - having less branches does not in any way stop them from having a fixed release process and schedule. It is about random release being chosen as LTS. For many users, it will preventing migration until a given feature is part of a LTS release. Our proposal to have fixed life time and release cycles does not have this random effect and each x.y release is equally supported for the same duration. The amount of branches can be reduced easily and even if we may have many at one point, it will be only about sec fixes, that's really not a problem (a bit of automated tasked will help here too). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org Johannes said: Every n-th current release will be a long term supported (LTS) release That doesn't sound very random to me if n is constant. That said, I'm not sure if an LTS is a good idea. One of the biggest frustrations for me as a developer is hosts taking forever to upgrade to newer versions of PHP. Most hosts I've seen are still on 5.2, and some don't seem to have plans of upgrading to 5.3 any time soon. To me, an LTS release would just make this situation worse, although the upside is that at least we'd still be getting security fixes. If however the LTS release lifetime is similar to the current y release (x.y.z) then maybe it won't be so bad as it would grant earlier and stable access to new features for those who have control over their php installs, while retain a more long term supported release that hosts would be happy with. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
Am 02.06.2011 11:36, schrieb David Muir: That said, I'm not sure if an LTS is a good idea. One of the biggest frustrations for me as a developer is hosts taking forever to upgrade to newer versions of PHP. Most hosts I've seen are still on 5.2, and some don't seem to have plans of upgrading to 5.3 any time soon. To me, an LTS release would just make this situation worse, although the upside is that at least we'd still be getting security fixes. If however the LTS release lifetime is similar to the current y release (x.y.z) then maybe it won't be so bad as it would grant earlier and stable access to new features for those who have control over their php installs, while retain a more long term supported release that hosts would be happy with you will always have idiots thinking old is stable and it is your choice to do not support customers with such setups and you have to define minimum requirements for projects this has nothing to do with LTS or not LTS as example: we require php5.3 and if somebody has a unusable hoster the domain is transferred to our infrastructure and all problems gone away signature.asc Description: OpenPGP digital signature
RE: [PHP-DEV] RFC: Short syntax for Arrays (redux)
-Original Message- From: John Crenshaw [mailto:johncrens...@priacta.com] Sent: 01 June 2011 23:00 Spot on. It has nothing to do with extra typing (and that sort of design is part of what ruined Ruby). My fingers move plenty fast and if extra characters make things more safe or more readable, I'll be the first to sign up. In this case, however, the extra characters just make things messy. 1. The most readable format is pure JSON Matter of opinion. I don't agree. 2. The most familiar format is pure JSON (because these same developers are almost certainly already using it in their jQuery code) Also matter of opinion, and of experience. Apart from the fact that my use of jQuery amounts to a few weeks out of a (mumble)-year programming career, no I don't use pure JSON for it - Javascript object literals, yes, but not pure JSON. 3. The most compact format is pure JSON Um. Depends. I would tend to write 'a': 'b' in JSON, but 'a'='b' in PHP. But YMMV. 4. The format most consistent with other languages is JSON Again, matter of experience. Last time I counted, I'd used upward of 30 different programming languages and dialects, some of which had very bizarre ways of representing things, and none of which (apart from Javascript!) used a JSON-like array-literal syntax. And, actually, I *want* my PHP arrays to look different from my Javascript/JSON arrays, especially as I might be looking at both as part of the same project -- I *want* a big data structure to scream I'm PHP or I'm Javascript/JSON at me, to help trigger my brain into the right programming mode. All of this is just IMHO, of course, and probably a lot more than my regulation 2 pennorth, but there you go. Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Leeds Metropolitan University, C507 City Campus, Portland Way, LEEDS, LS1 3HE, United Kingdom E: m.f...@leedsmet.ac.uk T: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
On 2 June 2011 10:23, Pierre Joye pierre@gmail.com wrote: On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind peter.e.l...@gmail.com wrote: Sorry for jumping into the thread, but I couldn't help noting that you seem confused about the distro suggestion. I think Ubuntu was the example, and there's nothing random at all about their release process. There are fixed timelines and life cycles in Ubuntu - having less branches does not in any way stop them from having a fixed release process and schedule. It is about random release being chosen as LTS. For many users, it will preventing migration until a given feature is part of a LTS release. Our proposal to have fixed life time and release cycles does not have this random effect and each x.y release is equally supported for the same duration. The amount of branches can be reduced easily and even if we may have many at one point, it will be only about sec fixes, that's really not a problem (a bit of automated tasked will help here too). Then it's an argument about wording, not content. See https://wiki.ubuntu.com/Releases : the LTS have fixed life time and come at fixed intervals - basically exactly the same you propose with fixed life time and release cycles. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Notice on array to string convertion
Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. Patch implementing that behavior change: https://gist.github.com/1004203 Patch to adapt the tests: https://gist.github.com/1004204 Cheers, Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
On Thu, Jun 02, 2011 at 12:19:36PM +0200, Patrick ALLAERT wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. +1 -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
Am 02.06.2011 12:19, schrieb Patrick ALLAERT: I would like to introduce an E_NOTICE when an array is silently converted to a string. what is new? a fatal error would be better here error_reporting = E_ALL | E_STRICT google: Notice: Array to string conversion signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Final version, RFC release process
Am 01.06.2011 14:44, schrieb Johannes Schlüter: I mentioned this before: I like the Ubuntu model: * One development branch for the next version * One current version * One long term supported version +1 The current version is aimed to give early access to new features, to avoid cases like traits which take years to come out while a bit more conservative users (and maybe distros) may stay on the LTS. Traits is a really good example here, indeed. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Notice on array to string convertion
Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. Patch implementing that behavior change: https://gist.github.com/1004203 Patch to adapt the tests: https://gist.github.com/1004204 Cheers, Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
On Thu, Jun 2, 2011 at 11:51 AM, Peter Lind peter.e.l...@gmail.com wrote: On 2 June 2011 10:23, Pierre Joye pierre@gmail.com wrote: On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind peter.e.l...@gmail.com wrote: Sorry for jumping into the thread, but I couldn't help noting that you seem confused about the distro suggestion. I think Ubuntu was the example, and there's nothing random at all about their release process. There are fixed timelines and life cycles in Ubuntu - having less branches does not in any way stop them from having a fixed release process and schedule. It is about random release being chosen as LTS. For many users, it will preventing migration until a given feature is part of a LTS release. Our proposal to have fixed life time and release cycles does not have this random effect and each x.y release is equally supported for the same duration. The amount of branches can be reduced easily and even if we may have many at one point, it will be only about sec fixes, that's really not a problem (a bit of automated tasked will help here too). Then it's an argument about wording, not content. See https://wiki.ubuntu.com/Releases : the LTS have fixed life time and come at fixed intervals - basically exactly the same you propose with fixed life time and release cycles. No, it is the same that what we proposed. What we proposed is that every release is actually a LTS release. What Ubuntu uses works fine for distros given that it is a distro with an insane amount of totally unrelated projects they distribute, and alternative repositories exist for almost each of them. For a programming language, it is a totally different story. for ref: https://wiki.ubuntu.com/LTS 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] Final version, RFC release process
On Thu, Jun 2, 2011 at 12:08 PM, Sebastian Bergmann sebast...@php.net wrote: The current version is aimed to give early access to new features, to avoid cases like traits which take years to come out while a bit more conservative users (and maybe distros) may stay on the LTS. Traits is a really good example here, indeed. Please tell me how it differs to what we propose? aka yearly release with fixed lifetime for each release? It is exactly about that, do not have unreasonable delay between a feature readiness and its availability in a release. While solving the plan-ability to migrate to a give version, or allow migrations to newer versions without risk. 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] RFC: Short syntax for Arrays (redux)
2011/6/2 Ford, Mike m.f...@leedsmet.ac.uk: -Original Message- From: John Crenshaw [mailto:johncrens...@priacta.com] Sent: 01 June 2011 23:00 skip 4. The format most consistent with other languages is JSON Again, matter of experience. Last time I counted, I'd used upward of 30 different programming languages and dialects, some of which had very bizarre ways of representing things, and none of which (apart from Javascript!) used a JSON-like array-literal syntax. And, actually, I *want* my PHP arrays to look different from my Javascript/JSON arrays, especially as I might be looking at both as part of the same project -- I *want* a big data structure to scream I'm PHP or I'm Javascript/JSON at me, to help trigger my brain into the right programming mode. All of this is just IMHO, of course, and probably a lot more than my regulation 2 pennorth, but there you go. Cheers! Mike My thinking too. Mixind PHP arrays JS JSON in one file with same syntax will be a major headache in the future for many. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote: *snip* No, it is the same that what we proposed. What we proposed is that every release is actually a LTS release. What Ubuntu uses works fine for distros given that it is a distro with an insane amount of totally unrelated projects they distribute, and alternative repositories exist for almost each of them. For a programming language, it is a totally different story. That makes more sense - you were, however, arguing against random LTS releases which was rather confusing (there's a big difference between every release is an LTS and all LTS releases are random - those are not the only options). Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind peter.e.l...@gmail.com wrote: On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote: *snip* No, it is the same that what we proposed. What we proposed is that every release is actually a LTS release. What Ubuntu uses works fine for distros given that it is a distro with an insane amount of totally unrelated projects they distribute, and alternative repositories exist for almost each of them. For a programming language, it is a totally different story. That makes more sense - you were, however, arguing against random LTS releases which was rather confusing (there's a big difference between every release is an LTS and all LTS releases are random - those are not the only options). The randomness is about which release-features tuples would become a LTS, that's something that can't apply well to a project like php. 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] Final version, RFC release process
On 2 June 2011 13:03, Pierre Joye pierre@gmail.com wrote: On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind peter.e.l...@gmail.com wrote: On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote: *snip* No, it is the same that what we proposed. What we proposed is that every release is actually a LTS release. What Ubuntu uses works fine for distros given that it is a distro with an insane amount of totally unrelated projects they distribute, and alternative repositories exist for almost each of them. For a programming language, it is a totally different story. That makes more sense - you were, however, arguing against random LTS releases which was rather confusing (there's a big difference between every release is an LTS and all LTS releases are random - those are not the only options). The randomness is about which release-features tuples would become a LTS, that's something that can't apply well to a project like php. It's hard to see how that would be any more or less random than now, given that it would still be a question of votes or consensus. Presumably, features would not be removed (unless they were bad for the language) and so they would still make it into LTS releases - the next one up. Anyway, I'll stop it here, as I doubt I'll convince you of anything (and vice versa). Just one thing to add: thanks for the work on PHP :) Much appreciated. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
On Thu, Jun 2, 2011 at 1:15 PM, Peter Lind peter.e.l...@gmail.com wrote: On 2 June 2011 13:03, Pierre Joye pierre@gmail.com wrote: On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind peter.e.l...@gmail.com wrote: On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote: *snip* No, it is the same that what we proposed. What we proposed is that every release is actually a LTS release. What Ubuntu uses works fine for distros given that it is a distro with an insane amount of totally unrelated projects they distribute, and alternative repositories exist for almost each of them. For a programming language, it is a totally different story. That makes more sense - you were, however, arguing against random LTS releases which was rather confusing (there's a big difference between every release is an LTS and all LTS releases are random - those are not the only options). The randomness is about which release-features tuples would become a LTS, that's something that can't apply well to a project like php. It's hard to see how that would be any more or less random than now, given that it would still be a question of votes or consensus. I was referring to accepted features. Once they are accepted (and implemented), our proposal makes sure that they will be in the next release, which will happen within a year. And this next release will have the same lifetime than any other. Presumably, features would not be removed (unless they were bad for the language) and so they would still make it into LTS releases - the next one up. That's a different topic and it is covered by the BC breakages policy. Only major versions bump allows that. Anyway, I'll stop it here, as I doubt I'll convince you of anything (and vice versa). Heh, that's why we discuss, exchange views and oppinions :) Just one thing to add: thanks for the work on PHP :) Much appreciated. You are welcome :) 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] Final version, RFC release process
Am 02.06.2011 13:15, schrieb Peter Lind: Anyway, I'll stop it here, as I doubt I'll convince you of anything (and vice versa). Just one thing to add: thanks for the work on PHP :) Much appreciated. I think/hope that this RFC is a step in the right direction to make the release process clearer and more transparent for every interested userland developer. So from me a big THANK YOU to all involved. Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT patrickalla...@php.net wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. How about making it useful rather then just throwing an notice? Recursive implode maybe? Or json/php serialized? :) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
I don't there's a good general case for this. I'd +1 on throwing E_NOTICE. Hannes On 2 June 2011 13:54, Hannes Magnusson hannes.magnus...@gmail.com wrote: How about making it useful rather then just throwing an notice? Recursive implode maybe? Or json/php serialized? :) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
Em Thu, 02 Jun 2011 12:54:10 +0100, Hannes Magnusson hannes.magnus...@gmail.com escreveu: On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT patrickalla...@php.net wrote: I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. How about making it useful rather then just throwing an notice? Recursive implode maybe? Or json/php serialized? :) That's a much bigger BC break and can cause trouble because the elements of the array may not be convertible to strings. I support the E_NOTICE idea. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
Am 02.06.2011 13:54, schrieb Hannes Magnusson: On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT patrickalla...@php.net wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. How about making it useful rather then just throwing an notice? Recursive implode maybe? Or json/php serialized? :) it is braindead to expect such bad magic in a programing-language normally this convertion happens when the programmer had made something wrong (forgot serialize as example), now you are coming and think JSON is cool and convert silently, so what will unserialize() do with this crap after reading the data from mysql? this conversion should never happen and throw a fatal error since this action is destructive to data and never useful nor will warnings/notices helps in the real world signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
this conversion should never happen and throw a fatal error since this action is destructive to data and never useful nor will warnings/notices helps in the real world Unlike i.e. Python its really not the PHP way to go fatal on the developer during weird type conversions. I'm also +1 on the E_NOTICE. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
Am 02.06.2011 14:56, schrieb Rune Kaagaard: this conversion should never happen and throw a fatal error since this action is destructive to data and never useful nor will warnings/notices helps in the real world Unlike i.e. Python its really not the PHP way to go fatal on the developer during weird type conversions. I'm also +1 on the E_NOTICE. this is not a weird conversion this is a idiotic one destroying data and 99 of 100 hosts never showing notices because you must not do this on the webpage and on shared host you have no access to the error-log - so what helps the notice the warning still exists but how will you repair Array in the textfiled of a database? signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
On Thu, Jun 2, 2011 at 6:24 AM, Reindl Harald h.rei...@thelounge.netwrote: Am 02.06.2011 13:54, schrieb Hannes Magnusson: On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT patrickalla...@php.net wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. How about making it useful rather then just throwing an notice? Recursive implode maybe? Or json/php serialized? :) it is braindead to expect such bad magic in a programing-language normally this convertion happens when the programmer had made something wrong (forgot serialize as example), now you are coming and think JSON is cool and convert silently, so what will unserialize() do with this crap after reading the data from mysql? this conversion should never happen and throw a fatal error since this action is destructive to data and never useful nor will warnings/notices helps in the real world First, I agree that converting to json/imploding would be a bad idea. There's no guarantee that the developer wanted to use the array in that way, or even that he wanted to use the array at all instead of some element inside the array. Instead, this is an indication that you're probably doing something wrong. However, fatal errors should be reserved for when the engine cannot continue. Disallowing the ability to catch and handle an error, even if it is just to display a prettier notification, is something to be avoided. P.S. your use of the words braindead/crap hurts your argument. :)
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
Am 02.06.2011 15:04, schrieb John LeSueur: On Thu, Jun 2, 2011 at 6:24 AM, Reindl Harald h.rei...@thelounge.netwrote: First, I agree that converting to json/imploding would be a bad idea. There's no guarantee that the developer wanted to use the array in that way, or even that he wanted to use the array at all instead of some element inside the array. and the dveloper surely wanted NOT write destroyed data somewhere Instead, this is an indication that you're probably doing something wrong. leave the world probably out However, fatal errors should be reserved for when the engine cannot continue. the engine can not continue anything useful after passing an array to a string function P.S. your use of the words braindead/crap hurts your argument. :) maybe but i find no other for such ideas P.S: would you and some others please only reply to the list and stop converting plaintext mails to html-messages? signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
3 yes please. Sent from my iBrain, powered by Panda. On Jun 2, 2011, at 6:19 AM, Patrick ALLAERT patrick.alla...@gmail.com wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. Patch implementing that behavior change: https://gist.github.com/1004203 Patch to adapt the tests: https://gist.github.com/1004204 Cheers, Patrick -- 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] [PATCH] Notice on array to string convertion
E_NOTICE. The current conversion is so completely useless, that whenever it happens, it is almost certainly an error. Any implicit conversion here would perpetuate problems in code that was probably wrong in the first place. John Crenshaw Priacta, Inc. -Original Message- From: John LeSueur [mailto:john.lesu...@gmail.com] Sent: Thursday, June 02, 2011 9:04 AM To: Reindl Harald Cc: internals@lists.php.net Subject: Re: [PHP-DEV] [PATCH] Notice on array to string convertion On Thu, Jun 2, 2011 at 6:24 AM, Reindl Harald h.rei...@thelounge.netwrote: Am 02.06.2011 13:54, schrieb Hannes Magnusson: On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT patrickalla...@php.net wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. How about making it useful rather then just throwing an notice? Recursive implode maybe? Or json/php serialized? :) it is braindead to expect such bad magic in a programing-language normally this convertion happens when the programmer had made something wrong (forgot serialize as example), now you are coming and think JSON is cool and convert silently, so what will unserialize() do with this crap after reading the data from mysql? this conversion should never happen and throw a fatal error since this action is destructive to data and never useful nor will warnings/notices helps in the real world First, I agree that converting to json/imploding would be a bad idea. There's no guarantee that the developer wanted to use the array in that way, or even that he wanted to use the array at all instead of some element inside the array. Instead, this is an indication that you're probably doing something wrong. However, fatal errors should be reserved for when the engine cannot continue. Disallowing the ability to catch and handle an error, even if it is just to display a prettier notification, is something to be avoided. P.S. your use of the words braindead/crap hurts your argument. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
2011/6/2 Hannes Magnusson hannes.magnus...@gmail.com: How about making it useful rather then just throwing an notice? Recursive implode maybe? Or json/php serialized? :) As already mentioned, that would be a much bigger BC break which would requires RFC, voting, ... Not that I am against, the thing is that it is difficult to know how this would have to be rendered. Some will prefer json, others a recursive join with ,, and so on. For the simplicity, I think it is best to let the user decide on which format to transform an array by explicitly call a function on it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
hi, I like this for the current stable branch, no bc impact and gives a way to detect such mistakes (not ideal but better than nothing). Cheers, On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERT patrickalla...@php.net wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. Patch implementing that behavior change: https://gist.github.com/1004203 Patch to adapt the tests: https://gist.github.com/1004204 Cheers, Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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] [PATCH] Notice on array to string convertion
2011/6/2 Rune Kaagaard rumi...@gmail.com:
this conversion should never happen and throw a fatal error since this
action is destructive to data and never useful nor will warnings/notices
helps in the real world
Unlike i.e. Python its really not the PHP way to go fatal on the
developer during weird type conversions. I'm also +1 on the E_NOTICE.
Indeed, an error is really not appropriate here as this is seldom used
in some very specific case (like testing php with phpt tests):
To test the method offsetGet(), an echo is made with the call to the
method and the parameters.
That way we see in the expected part that we are calling it with
offsetGet(Array,anIndex)...
function offsetGet($index) {
echo __METHOD__ . ($this-element, $index)\n;
return isset($this-element[$index]) ? $this-element[$index] : NULL;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
I like this for the current stable branch, no bc impact and gives a way to detect such mistakes (not ideal but better than nothing). On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERTpatrickalla...@php.net wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. I agree with Peirre and would actually support this as an E_WARNING. Since there is a patch for E_NOTICE already, I will take it. -- Brian. http://brian.moonspot.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
2011/6/2 Reindl Harald h.rei...@thelounge.net:
Am 02.06.2011 15:04, schrieb John LeSueur:
On Thu, Jun 2, 2011 at 6:24 AM, Reindl Harald h.rei...@thelounge.netwrote:
First, I agree that converting to json/imploding would be a bad idea.
There's no guarantee that the developer wanted to use the array in that way,
or even
that he wanted to use the array at all instead of some element inside the
array.
and the dveloper surely wanted NOT write destroyed data somewhere
Yes, but we also don't want to break BC.
Instead, this is an indication that you're probably doing something wrong.
leave the world probably out
However, fatal errors should be reserved for when the engine cannot
continue.
the engine can not continue anything useful after passing
an array to a string function
Not true. Here is a valid example that would break after implementing
this as en error.
if ($x == Array) {
array_walk( $x, print_r );
}
I'm not saying that this is good code, I'm only saying that this would
break BC which is even worst.
Not only this wouldn't be a huge BC break, this would also lead to
some incoherence. For now, if you are using:
$x = array();
join( $x, array( element1, element2) );
This will already generate a notice:
Notice: Array to string conversion in ... on line ...
This would lead to two choice:
1. Be incoherent (with the rest of the code and the philosophy of PHP)
2. Be coherent and make all those functions already generating a
notice be an error. That would be even a much much much larger BC
break.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
2011/6/2 Brian Moon br...@moonspot.net: I like this for the current stable branch, no bc impact and gives a way to detect such mistakes (not ideal but better than nothing). On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERTpatrickalla...@php.net wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. I agree with Peirre and would actually support this as an E_WARNING. Since there is a patch for E_NOTICE already, I will take it. I am going to commit this after the WE to let the chance to other people to comment on. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Short syntax for Arrays (redux)
Even though I have quite mixed feelings about this, I think I am
finally ready to cast
my +1. Over the past few days I've discussed with a few people and
noticed the need, or rather a strong desire to have this feature in
PHP and most people seemed to care only little about how it was done
as long as it was done.
For the record, my initial objection with the array literals was never
the array literals themselves but the lack of object literals to
accompany the patch. I still strongly believe that we need both arrays
[] and objects {} for a complete consistent implementation,
however I'm willing to make a compromise and move forward rather than stalling.
Consider this my official +1 for [key = value]
--
David Coallier
--
David Coallier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
On Thu, Jun 02, 2011 at 04:07:25PM +0200, Patrick ALLAERT wrote:
Not true. Here is a valid example that would break after implementing
this as en error.
if ($x == Array) {
array_walk( $x, print_r );
}
I'm not saying that this is good code, I'm only saying that this would
break BC which is even worst.
Good point.
The real problem is that there are 2 sorts of PHP programmers.
1) those who will be grateful of anything that can help them find errors
in their code - these look at the error logs and correct their code.
2) those who write in a rush and as long as it appears to generate about
the right sort of results are happy, they don't care for anything else.
Unfortunately too many programmers are of type (2). They will bitch at what
they (in some ways rightly) see as a break in BC.
Maybe we ought to make it a warning for the PHP 5 series and an error for
PHP 6. Breaks in BC are more acceptable at major releases.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
I am not convinced that making this an error is a good idea.
If I receive a $_GET/$_POST value that I expect to be a string value,
but I actually received an array, this would mean I need to now
explicitly check for it, since it will stop the runtime otherwise. Example:
http://home.sweet.home/list.php?cheese[]=briecheese[]=goat
Array
(
[cheese] = Array
(
[0] = brie
[1] = goat
)
)
That just makes it more verbose. An E_NOTICE is fine; it won't stop
anything, and it will show up in my error log. Another alternative I can
think of would be to throw an exception, since it's catchable. However,
we need to be aware that user input can generate this condition also,
and it shouldn't necessarily explode my process.
Just my 2 cents.
- M.
On 6/2/2011 10:17 AM, Alain Williams wrote:
On Thu, Jun 02, 2011 at 04:07:25PM +0200, Patrick ALLAERT wrote:
Not true. Here is a valid example that would break after implementing
this as en error.
if ($x == Array) {
array_walk( $x, print_r );
}
I'm not saying that this is good code, I'm only saying that this would
break BC which is even worst.
Good point.
The real problem is that there are 2 sorts of PHP programmers.
1) those who will be grateful of anything that can help them find errors
in their code - these look at the error logs and correct their code.
2) those who write in a rush and as long as it appears to generate about
the right sort of results are happy, they don't care for anything else.
Unfortunately too many programmers are of type (2). They will bitch at what
they (in some ways rightly) see as a break in BC.
Maybe we ought to make it a warning for the PHP 5 series and an error for
PHP 6. Breaks in BC are more acceptable at major releases.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
On Thu, 02 Jun 2011 15:38:00 +0200, Brian Moon br...@moonspot.net wrote: I like this for the current stable branch, no bc impact and gives a way to detect such mistakes (not ideal but better than nothing). On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERTpatrickalla...@php.net wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. I agree with Peirre and would actually support this as an E_WARNING. Since there is a patch for E_NOTICE already, I will take it. I would also support an E_WARNING for this; but as I mostly develop in environments where E_NOTICE issues are taken care of, E_NOTICE is fine with me. -- Ole Markus http://barelysufficient.org Gentoo/Linux - PHP Herd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Request for Comments: Release Process: version numbering
Hi all, I've just read the Release Process RFC (https://wiki.php.net/rfc/releaseprocess) and have a suggestion regarding this part of the version numbering scheme: x.y.z to x.y+1.z. I believe x.y.z to x.y+1.0 is much more clear and common and less of a departure from the current numbering scheme. Then again, the current notation in the RFC might just be a typo :-) Best regards, Tomas Creemers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
+1 Sent from my iPhone On Jun 2, 2011, at 4:19 AM, Patrick ALLAERT patrick.alla...@gmail.com wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. Patch implementing that behavior change: https://gist.github.com/1004203 Patch to adapt the tests: https://gist.github.com/1004204 Cheers, Patrick -- 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] [PATCH] Notice on array to string convertion
The choice between E_WARNING and E_NOTICE is simple if we look at the definitions of the levels (http://php.net/manual/en/errorfunc.constants.php). E_NOTICE is defined as Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script. E_WARNING is defined as Run-time warnings (non-fatal errors). Execution of the script is not halted. Since the code example provided by Marcel Esser (expecting a string as a $_GET parameter but receiving an array) indicates that this conversion is not neccesarlily an error (and E_WARNING is just a non-fatal error), the conclusion is that this conversion should trigger an E_NOTICE. Best regards, Tomas Creemers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean I need to now explicitly check for it, since it will stop the runtime otherwise. so fix your code jesus christ what do you do if you expect a string and get an array? nothing useful! you can get this only by define name=multi[] in a form and so if you define there post an array you should not expect a string in the code, this is exactly a sample where a fatal error should be thworn to force peopole not writing crappy code which floods my error-logs if anybody out there means to put a self-written script on our servers with E_ALL | E_STRICT which are running in this mode since years would this be an error the blind developers would see them even on their development-machines signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
You don't need a form to receive bad user input. Also, I am not really inclined to write $v = isset($_POST['x']) ? (is_array($_POST['x']) ? 'something else that makes more sense' : $_POST['x'] ) : null; just to avoid catching a fatal. - M. On 6/2/2011 10:50 AM, Reindl Harald wrote: Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean I need to now explicitly check for it, since it will stop the runtime otherwise. so fix your code jesus christ what do you do if you expect a string and get an array? nothing useful! you can get this only by define name=multi[] in a form and so if you define there post an array you should not expect a string in the code, this is exactly a sample where a fatal error should be thworn to force peopole not writing crappy code which floods my error-logs if anybody out there means to put a self-written script on our servers with E_ALL | E_STRICT which are running in this mode since years would this be an error the blind developers would see them even on their development-machines
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
On 2 June 2011 16:50, Reindl Harald h.rei...@thelounge.net wrote: Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean I need to now explicitly check for it, since it will stop the runtime otherwise. so fix your code jesus christ How about you take your medication, then chill down, then consider your messages a couple of times before sending? It would make the atmosphere quite a bit nicer. Regards Peter -- hype WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 /hype -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
Am 02.06.2011 14:56, schrieb Rune Kaagaard: this conversion should never happen and throw a fatal error since this action is destructive to data and never useful nor will warnings/notices helps in the real world I agree totally that such a conversion should never happen. If we could redesign PHP from the ground up, that would be great thing to change. But making such a big BC break is just very impractical. PHP is an extremely loose language, that is probably never going to change. this is not a weird conversion this is a idiotic one destroying data and 99 of 100 hosts never showing notices because you must not do this on the webpage and on shared host you have no access to the error-log - so what helps the notice If you are not checking your E_NOTICES you are truly on your own and PHP can not help you. I'm OK with that! An unintended (string)array() cast is just one of many things that can go wrong. Even on hosted servers enlightened PHP developers can use set_error_handler() and register_shutdown_function() to log errors. On the other hand, then many developers don't care about checking for errors, thats fine too. PHP is supposed to be an entry level language, lets not try and change that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
first rule of programming: sanitize user input if you EXPECT no array catch it Am 02.06.2011 16:54, schrieb Marcel Esser: You don't need a form to receive bad user input. Also, I am not really inclined to write $v = isset($_POST['x']) ? (is_array($_POST['x']) ? 'something else that makes more sense' : $_POST['x'] ) : null; just to avoid catching a fatal. On 6/2/2011 10:50 AM, Reindl Harald wrote: Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean I need to now explicitly check for it, since it will stop the runtime otherwise. so fix your code jesus christ what do you do if you expect a string and get an array? nothing useful! you can get this only by define name=multi[] in a form and so if you define there post an array you should not expect a string in the code, this is exactly a sample where a fatal error should be thworn to force peopole not writing crappy code which floods my error-logs if anybody out there means to put a self-written script on our servers with E_ALL | E_STRICT which are running in this mode since years would this be an error the blind developers would see them even on their development-machines -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
On Jun 2, 2011, at 8:01 AM, Peter Lind wrote: On 2 June 2011 16:50, Reindl Harald h.rei...@thelounge.net wrote: Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean I need to now explicitly check for it, since it will stop the runtime otherwise. so fix your code jesus christ How about you take your medication, then chill down, then consider your messages a couple of times before sending? It would make the atmosphere quite a bit nicer. We all have our bad days and times when pressing submit fast feels like a good idea, but we do cover the topic here: - http://php.net/reST/php-src/trunk_README.MAILINGLIST_RULES It's good to digest this every so often, especially as a thread grows. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
I agree entirely. Let me go ahead and fix these three billion man hours worth of code in use through-out the world. I'll be back shortly. - M. On 6/2/2011 11:19 AM, Reindl Harald wrote: first rule of programming: sanitize user input if you EXPECT no array catch it Am 02.06.2011 16:54, schrieb Marcel Esser: You don't need a form to receive bad user input. Also, I am not really inclined to write $v = isset($_POST['x']) ? (is_array($_POST['x']) ? 'something else that makes more sense' : $_POST['x'] ) : null; just to avoid catching a fatal. On 6/2/2011 10:50 AM, Reindl Harald wrote: Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean I need to now explicitly check for it, since it will stop the runtime otherwise. so fix your code jesus christ what do you do if you expect a string and get an array? nothing useful! you can get this only by define name=multi[] in a form and so if you define there post an array you should not expect a string in the code, this is exactly a sample where a fatal error should be thworn to force peopole not writing crappy code which floods my error-logs if anybody out there means to put a self-written script on our servers with E_ALL | E_STRICT which are running in this mode since years would this be an error the blind developers would see them even on their development-machines -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
Am 02.06.2011 17:01, schrieb Peter Lind: On 2 June 2011 16:50, Reindl Harald h.rei...@thelounge.net wrote: Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean I need to now explicitly check for it, since it will stop the runtime otherwise. so fix your code jesus christ How about you take your medication, then chill down, then consider your messages a couple of times before sending? It would make the atmosphere quite a bit nicer. how about people learning basics instead say this would mean I need to now explicitly check somebody should silent shame why he does not? after that i can guess the rest of coding quality and this programing-styles are the reason for so many hours of work if somebody out there comes with his code to our servers (this does not often happen, but too often) and the reason for most security problems out there signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
I'm pretty sure you've never seen my code, so I am not going to comment on that. However, speaking not just for myself, two ternary operations and two functions calls to just prevent a stoppage code of execution, never mind input filtering for a second, is not entirely reasonable considering the vast majority of deployed code. This has traditionally been handled with deprecation, not by blowing up the runtime. That is why I think it's a bad idea. I recognize your opinion; however, that sounded a lot like a personal attack, for which I have no inclination to listen. Bitte, reg dich ab. - M. On 6/2/2011 11:34 AM, Reindl Harald wrote: Am 02.06.2011 17:01, schrieb Peter Lind: On 2 June 2011 16:50, Reindl Haraldh.rei...@thelounge.net wrote: Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean I need to now explicitly check for it, since it will stop the runtime otherwise. so fix your code jesus christ How about you take your medication, then chill down, then consider your messages a couple of times before sending? It would make the atmosphere quite a bit nicer. how about people learning basics instead say this would mean I need to now explicitly check somebody should silent shame why he does not? after that i can guess the rest of coding quality and this programing-styles are the reason for so many hours of work if somebody out there comes with his code to our servers (this does not often happen, but too often) and the reason for most security problems out there -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
may I suggest to both of you to continue this rant off line please? The initial question was rather simple and only about this specific case. And we seem to agree on the necessity to have a notice/warning here. That's the maximum we can do at this stage, both for 5.3 and 5.4. On Thu, Jun 2, 2011 at 5:43 PM, Marcel Esser marcel.es...@croscon.com wrote: I'm pretty sure you've never seen my code, so I am not going to comment on that. However, speaking not just for myself, two ternary operations and two functions calls to just prevent a stoppage code of execution, never mind input filtering for a second, is not entirely reasonable considering the vast majority of deployed code. This has traditionally been handled with deprecation, not by blowing up the runtime. That is why I think it's a bad idea. I recognize your opinion; however, that sounded a lot like a personal attack, for which I have no inclination to listen. Bitte, reg dich ab. - M. On 6/2/2011 11:34 AM, Reindl Harald wrote: Am 02.06.2011 17:01, schrieb Peter Lind: On 2 June 2011 16:50, Reindl Haraldh.rei...@thelounge.net wrote: Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean I need to now explicitly check for it, since it will stop the runtime otherwise. so fix your code jesus christ How about you take your medication, then chill down, then consider your messages a couple of times before sending? It would make the atmosphere quite a bit nicer. how about people learning basics instead say this would mean I need to now explicitly check somebody should silent shame why he does not? after that i can guess the rest of coding quality and this programing-styles are the reason for so many hours of work if somebody out there comes with his code to our servers (this does not often happen, but too often) and the reason for most security problems out there -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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] RFC: Zend Signal Handling
hi Ilia, I would suggest to kill the TSRMLS_FETCH while being at it. They are horribly slow and a couple of them can be replaced by the TSRMLS_DC/CC, if I'm not mistaken. For the windows side, I do not have the time to do the equivalent, so if you commit the patch to trunk first so I can fix the build accordingly and then merge, that would be easier for me :). Cheers, On Wed, Jun 1, 2011 at 12:30 AM, Ilia Alshanetsky i...@prohost.org wrote: Since we are on the topic of reviewing past RFCs for 5.4, can we take another look at the Zend Signals RFC: https://wiki.php.net/rfc/zendsignals The patch is solid (have been using it in production for quite some time) and improvement is quite helpful, especially when APC is being used. Are there any reasons not to apply this to 5.4? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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] RFC: Short syntax for Arrays (redux)
Could we first go out with fully JSON compatible version for 5.4? and then later decide the = stuff based on how that worked. Native JSON is a big stuff for userland, and I'm pretty sure it will bring a hole of core version upgrades. Martin Scotta On Wed, Jun 1, 2011 at 7:09 PM, Sean Coates s...@seancoates.com wrote: Now, the only reason I would personally support the array shortcut is if it was an implementation of JSON. I know that's not on the table here I don't think anything is officially off the table, unless we forego discussion. My application is largely JSON-powered. We pass data from back- to front-end via JSON, we interact with MongoDB via the extension (which is an altered JSON-like protocol (arrays instead of objects), but would be a lot more fluent with actual objects—they're just too hard to make in current PHP), and we interface with ElasticSearch. The paste I linked earlier is our primary ElasticSearch query. The benefits of first-class JSON are important and wide-reaching; especially when interacting with systems like the ones I've mentioned. There's a huge amount of value in being able to copy JSON out of PHP and into e.g. CURL to make a query to ElasticSearch without worrying that I've accidentally nested one level too deep or shallow, or accidentally mistranslating my arrays into JSON. This is not about saving five characters every time I type array(), it's about making my systems all work together in a way that's a little less abstracted, and a lot less prone to error. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
reminder #2, pls do vote here: https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did not choose which syntax they want. Thanks, On Tue, May 31, 2011 at 8:42 PM, Brian Moon br...@moonspot.net wrote: https://wiki.php.net/rfc/shortsyntaxforarrays -- 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] [PATCH] Notice on array to string convertion
2011/6/2 Reindl Harald h.rei...@thelounge.net: Am 02.06.2011 16:24, schrieb Marcel Esser: I am not convinced that making this an error is a good idea. If I receive a $_GET/$_POST value that I expect to be a string value, but I actually received an array, this would mean I need to now explicitly check for it, since it will stop the runtime otherwise. so fix your code jesus christ I am not sure he has anything to do with that. what do you do if you expect a string and get an array? nothing useful! That is not the point, when you cast an array as a string, you are supposed to receive Array whether you like this or not. For now, this is just a silent operation which I want to make some noise, accordingly to the philosophy of PHP. Most of the time, this is a sign of error, obviously, there are some very few case where you want that conversion, may I point you to the PHP unit tests (*.phpt files)? you can get this only by define name=multi[] in a form and so if you define there post an array you should not expect a string in the code, this is exactly a sample where a fatal error should be thworn to force peopole not writing crappy code which floods my error-logs if anybody out there means to put a self-written script on our servers with E_ALL | E_STRICT which are running in this mode since years would this be an error the blind developers would see them even on their development-machines I'm all for errors being reported as it should be, the key here is that casting an array to string should remain a permitted operation. The same is true when using a variable which is not declared. If you don't agree with that, you don't agree with the whole principle of PHP's notices which is of course debatable. May I invite you to discuss the fact that PHP's notice are inappropriate in software development in a specific thread? I am sure some people could help you in this task or even to create an RFC about how to change that in the future of PHP. Regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Zend Signal Handling
On 05/31/2011 03:30 PM, Ilia Alshanetsky wrote: Since we are on the topic of reviewing past RFCs for 5.4, can we take another look at the Zend Signals RFC: https://wiki.php.net/rfc/zendsignals The patch is solid (have been using it in production for quite some time) and improvement is quite helpful, especially when APC is being used. Are there any reasons not to apply this to 5.4? Can you post an updated patch? Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Zend Signal Handling
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch at a time please ;-) And for the record I am all for killing TSRMLS_FETCH. On Thu, Jun 2, 2011 at 6:04 PM, Pierre Joye pierre@gmail.com wrote: hi Ilia, I would suggest to kill the TSRMLS_FETCH while being at it. They are horribly slow and a couple of them can be replaced by the TSRMLS_DC/CC, if I'm not mistaken. For the windows side, I do not have the time to do the equivalent, so if you commit the patch to trunk first so I can fix the build accordingly and then merge, that would be easier for me :). Cheers, On Wed, Jun 1, 2011 at 12:30 AM, Ilia Alshanetsky i...@prohost.org wrote: Since we are on the topic of reviewing past RFCs for 5.4, can we take another look at the Zend Signals RFC: https://wiki.php.net/rfc/zendsignals The patch is solid (have been using it in production for quite some time) and improvement is quite helpful, especially when APC is being used. Are there any reasons not to apply this to 5.4? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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] [PATCH] Notice on array to string convertion
I like the idea of an error message when this happens, but as few other people in the thread had mentioned, I think it should be a warning (E_WARNING) because the conversion results in data loss (content of the array is replaced with Array string). On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERT patrickalla...@php.net wrote: Hi, I would like to introduce an E_NOTICE when an array is silently converted to a string. This isn't very useful as it constantly produces the following string: Array and in most of the case, this is a sign of an error. Let me know about your feelings. Patch implementing that behavior change: https://gist.github.com/1004203 Patch to adapt the tests: https://gist.github.com/1004204 Cheers, Patrick -- 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] RFC: Zend Signal Handling
On Thu, Jun 2, 2011 at 7:10 PM, Ilia Alshanetsky i...@prohost.org wrote: Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch at a time please ;-) I mean in this patch only. This patch adds a couple, so it can be done at the same time (afair these functions are not used heavily outside the engine). And for the record I am all for killing TSRMLS_FETCH. Same here (tls and some other ideas may help :) On Thu, Jun 2, 2011 at 6:04 PM, Pierre Joye pierre@gmail.com wrote: hi Ilia, I would suggest to kill the TSRMLS_FETCH while being at it. They are horribly slow and a couple of them can be replaced by the TSRMLS_DC/CC, if I'm not mistaken. For the windows side, I do not have the time to do the equivalent, so if you commit the patch to trunk first so I can fix the build accordingly and then merge, that would be easier for me :). Cheers, On Wed, Jun 1, 2011 at 12:30 AM, Ilia Alshanetsky i...@prohost.org wrote: Since we are on the topic of reviewing past RFCs for 5.4, can we take another look at the Zend Signals RFC: https://wiki.php.net/rfc/zendsignals The patch is solid (have been using it in production for quite some time) and improvement is quite helpful, especially when APC is being used. Are there any reasons not to apply this to 5.4? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- 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] RFC: Zend Signal Handling
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org escreveu: Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch at a time please ;-) And for the record I am all for killing TSRMLS_FETCH. Is there any advantage in killing it as opposed to simply not use it? You will be breaking a lot of extensions. Some of them depend on libraries with functions that receive callbacks to which you cannot pass specific user data, which unnecessarily complicates refactoring. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Also matter of opinion, and of experience. Apart from the fact that my use of jQuery amounts to a few weeks out of a (mumble)-year programming career, no I don't use pure JSON for it - Javascript object literals, yes, but not pure JSON. It's not just you. The claim that people regularly pass JSON strings within JS frameworks is comical; it would be about as smart as passing serialized PHP vars between PHP functions. I *want* my PHP arrays to look different from my Javascript/JSON arrays, especially as I might be looking at both as part of the same project -- I *want* a big data structure to scream I'm PHP or I'm Javascript/JSON at me, to help trigger my brain into the right programming mode. +1 -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Short syntax for Arrays (redux)
There's no need to be rude. If you can't make your point without attacking
people, then you need a better argument.
JSON in this case just means a simple object notation using {, [, and :. You
know that. Yes, we're all abusing the term, just like we all abuse AJAX,
regardless of the fact that almost nobody ACTUALLY uses XML as the transfer
encoding. Who cares? JSON is the best word available. Unless you can suggest
a better word to differentiate this format from the others (one that isn't
designed to insult anyone who disagrees with you) stop fussing about it.
John Crenshaw
Priacta, Inc.
From: Eloy Bote Falcon [mailto:eloyb...@gmail.com]
Sent: Thursday, June 02, 2011 3:58 AM
To: Sanford Whiteman
Cc: John Crenshaw; PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
2011/6/2 Sanford Whiteman
swhitemanlistens-softw...@cypressintegrated.commailto:swhitemanlistens-softw...@cypressintegrated.com
I don't think anyone cares about JSON for the sake of being perfect
JSON, I didn't intend to give that impression.
Then you should stop saying pure JSON and true JSON constantly!
I'm only hoping for something that generally works on par with all
the other JSON parsers in the world.
OK, that trashes your example, where values were set based on the
result of a PHP function. There is no par for JSON parsers running
methods _at creation time_, within the server (author) context.
Setting vars to the return value of a function is something we take
for granted in real languages, but it cannot happen within what a
knowledgeable person would call JSON.
Yes, JSON is a very specific encoding, but when a developer writes
something jsony, what they mean is an object/array with the
following structure/values, because that is what the encoding
really represents.
Not Javascript developers. Maybe jQiddies think that
{'$gt': strtotime('-1 day')}
is JSONy more than it is JS objecty?
This is like starting from Wouldn't inline CSVs be great for creating
arrays? and drifting to I mean, not like with that comma-escaping
stuff, and, uh, newlines would be allowed in the middle of a record,
and you'd have to allow create-time interpolation of function calls.
You know, CSVy!
Only thing I might generously refer to as being JSONy, while
provably not being valid JSON, is a string that conforms in every way
_except_ for using single quotes -- everywhere that doubles are
required -- instead of using doubles. Anything else is someone's
mangled JankySON or just not JSON.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-1 to the RFC.
+1 to = against : if the array short syntax it's finally implemented.
I, being a lazy programmer, don't want anymore new syntax to do the same thing.
I don't care if it a) saves me houndred of kaystrokes in the definition of
arrays, or if b) it's more familiar with _put_your_favorite_syntax_here_
because:
a) I prefer the simple way of _this_ is done _this_ way against _this_ is done
_this_ way or _this_another_ way or _this_yet_another_ way.
b) When another new fancy tendency of encoding appear I don't want to see it in
the core, because another one will appear in the future and then we will be in
the same point, stacking stuff forever or talking about deprecating the old and
breaking BC.
My point is: I'm for implementing something that can't be done currently in
PHP, but against for implementing another way of doing the same.
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
No we can't; I already explained why in another email last night. Copypasta:
json_decode() can deal with Unicode sequences because decodes to UTF-8. That is
not possible in a language construct:
What if I do this, in a latin1 encoded file:
$x = {foo: ä, bar: \u0123}
Should that then give mixed encodings? The ä in foo in latin1 and the stuff
in bar in UTF-8?
And what if I do:
$x = {foo: ä\u0123}
I'll either end up with an invalid UTF-8 sequence, or with latin1 character
soup.
David
On 02.06.2011, at 18:04, Martin Scotta martinsco...@gmail.com wrote:
Could we first go out with fully JSON compatible version for 5.4?
and then later decide the = stuff based on how that worked.
Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.
Martin Scotta
On Wed, Jun 1, 2011 at 7:09 PM, Sean Coates s...@seancoates.com wrote:
Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here
I don't think anything is officially off the table, unless we forego
discussion.
My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which is an
altered JSON-like protocol (arrays instead of objects), but would be a lot
more fluent with actual objects—they're just too hard to make in current
PHP), and we interface with ElasticSearch. The paste I linked earlier is our
primary ElasticSearch query.
The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP and
into e.g. CURL to make a query to ElasticSearch without worrying that I've
accidentally nested one level too deep or shallow, or accidentally
mistranslating my arrays into JSON.
This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Local PHP docs with search facility
Could some kind soul advise me on how to install php docs localy and have the excellent patterns search work based on an sqllite database? I have a local install but only full function names match but something like http://localhost/phpman/manual-lookup.php?pattern=str does not. A quick google hasn't helped but any refinements greatfully received! regards r. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
pls do vote here: https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did not choose which syntax they want. If people vote on this now, will further discussion about how this SHOULD work be shut down with we already voted on this? S
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
which other discussions do you wish? Json is clearly not an option and not enough people (but a couple) likes or wants it. The RFC is about short array syntax and as far as I can see there is already a clear consensus for one of the proposed new syntax. Cheers, On Thu, Jun 2, 2011 at 9:53 PM, Sean Coates s...@seancoates.com wrote: pls do vote here: https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did not choose which syntax they want. If people vote on this now, will further discussion about how this SHOULD work be shut down with we already voted on this? S -- 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] RFC: Short syntax for Arrays (redux)
so put +1 on both :D On Thu, Jun 2, 2011 at 9:37 PM, Brian Moon br...@moonspot.net wrote: On 6/2/11 11:08 AM, Pierre Joye wrote: reminder #2, pls do vote here: https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did not choose which syntax they want. I don't really care which syntax wins as long as one of them gets rolled in. Brian. -- 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] RFC: Short syntax for Arrays (redux)
On 6/2/11 11:08 AM, Pierre Joye wrote: reminder #2, pls do vote here: https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did not choose which syntax they want. I don't really care which syntax wins as long as one of them gets rolled in. Brian. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
There's no need to be rude. If you can't make your point without
attacking people, then you need a better argument.
If you can't make your point without misusing terms to the point of
making yourself untrustworthy on that level alone, stop trying to
argue.
The lazy programmer axiom doesn't apply to terminology.
JSON in this case just means a simple object notation using {, [,
and :. You know that.
Nope. I have NEVER heard a knowledgeable developer use JSON in this
way. I consider myself a mid-level Javascript developer, so I'm always
learning both formal coding patterns and informal jargon from people
at the expert level -- but I've never heard this. Evidence, please,
for this claim that the term JSON is so abused by people who
provably know better.
JSON is the best word available.
Give me a break.
JavaScript object literal.
As above, no knowledgeable JS dev refers to
{ name : function(args) }
as actual or informal JSON.
Unless you can suggest a better word to differentiate this format
from the others (one that isn't designed to insult anyone who
disagrees with you) stop fussing about it.
You explicitly claimed that any browser will take your
JSON-with-interpolated-function-return. And you firmly stated you
wanted par with all the other JSON parsers in the world.
You're saying that, um, JSON parser and JavaScript engine are
known to be interchangeable?
Please, just... stop. The time taken here could be better spent
reading the JSON and ES-232 specs than making up false common
knowledge.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Hi! https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did not choose which syntax they want. Just to be clear on my vote, I'd really like to have [], and I think we MUST keep = there, but I don't care either way about ':'. -- 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] RFC: Short syntax for Arrays (redux)
If people vote on this now, will further discussion about how this SHOULD work be shut down with we already voted on this? which other discussions do you wish? Json is clearly not an option and not enough people (but a couple) likes or wants it. The RFC is about short array syntax and as far as I can see there is already a clear consensus for one of the proposed new syntax. I don't see why JSON (or JSON-like, or JavaScript Object Literal, or whatever the least politically-fired term of the moment) syntax is clearly not an option. I'm considering writing a new RFC that calls for first-class JSONishy syntax, but I have better things to do if it's already dead in the water. As much as I'd like to avoid drawing out this discussion, I think a premature vote that will be used as a political wedge to shut down all future syntaxes that don't use T_ARRAY is not in the best interest of PHP. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Stop spreading FUD, please.
It's no different than writing json_decode(ä\u0123).
Your statement, the stuff in bar in UTF-8 is wrong. The \u0123
escape sequence is a representation of a Unicode character, not the
character itself. This representation can be encoded in any
ASCII-compatible encoding, such as Latin-1, UTF-8, etc. So putting it
directly in a Latin-1 encoded script is just fine.
-Andrei
On Thu, Jun 2, 2011 at 12:00 PM, David Zülke
david.zue...@bitextender.com wrote:
No we can't; I already explained why in another email last night. Copypasta:
json_decode() can deal with Unicode sequences because decodes to UTF-8. That
is not possible in a language construct:
What if I do this, in a latin1 encoded file:
$x = {foo: ä, bar: \u0123}
Should that then give mixed encodings? The ä in foo in latin1 and the stuff
in bar in UTF-8?
And what if I do:
$x = {foo: ä\u0123}
I'll either end up with an invalid UTF-8 sequence, or with latin1 character
soup.
David
On 02.06.2011, at 18:04, Martin Scotta martinsco...@gmail.com wrote:
Could we first go out with fully JSON compatible version for 5.4?
and then later decide the = stuff based on how that worked.
Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.
Martin Scotta
On Wed, Jun 1, 2011 at 7:09 PM, Sean Coates s...@seancoates.com wrote:
Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here
I don't think anything is officially off the table, unless we forego
discussion.
My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which is an
altered JSON-like protocol (arrays instead of objects), but would be a lot
more fluent with actual objects—they're just too hard to make in current
PHP), and we interface with ElasticSearch. The paste I linked earlier is our
primary ElasticSearch query.
The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP and
into e.g. CURL to make a query to ElasticSearch without worrying that I've
accidentally nested one level too deep or shallow, or accidentally
mistranslating my arrays into JSON.
This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.
S
--
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-DEV] 5.4 moving forward
Hi! We're having pretty lively discussion on the list, twitter and other places, but let's not forget the big goal of 5.4 :) 1. First of all, the official business. Any objections to the RMs for 5.4 being: Stas Malyshev (stas) David Soria Parra (dsp) If not, we'll be the 5.4 RM team. 2. Candidates for 5.4: please review this list: https://wiki.php.net/todo/php54 I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Some of the items are already being discussed, but I'll prepare some kind of official ballot and send to the list soon so we'd have common point. I think it makes sense to have the following limits of the features: a. It should be either obvious how to do it (example: adding E_STRICT to E_ALL), or have full design working patch w/tests or somebody has to commit to doing it within roughly a month term. b. I think we should leave out any big things now, e.g.: annotations - sorry, I know there are many people supporting it, but right now it doesn't seem to be a consensus on how to do it, so I'd rather target 5.5 for it, which if we can make this release go smoothly won't have to be too far out. 3. I'd like to create first alpha sometime next week, if somebody has anything that's not in and wants it in please talk to me. This alpha should in no way be seen as anything stable or final, but rather as a first step on a road to 5.4. -- 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] RFC: Short syntax for Arrays (redux)
On Jun 2, 2011, at 1:19 PM, Sean Coates wrote: If people vote on this now, will further discussion about how this SHOULD work be shut down with we already voted on this? which other discussions do you wish? Json is clearly not an option and not enough people (but a couple) likes or wants it. The RFC is about short array syntax and as far as I can see there is already a clear consensus for one of the proposed new syntax. I don't see why JSON (or JSON-like, or JavaScript Object Literal, or whatever the least politically-fired term of the moment) syntax is clearly not an option. I'm considering writing a new RFC that calls for first-class JSONishy syntax, but I have better things to do if it's already dead in the water. As much as I'd like to avoid drawing out this discussion, I think a premature vote that will be used as a political wedge to shut down all future syntaxes that don't use T_ARRAY is not in the best interest of PHP. I share this concern, and it applies to future topics and discussions. I think you creating this RFC would be helpful, and that we as a group should respect the desired timeline for proposing this alternative RFC (I assume over the weekend?). We won't be forgetting this topic (it feels like people are panicking like we will) so if said alternative isn't available or doesn't gain traction then the current [adjusted] RFC should be implemented. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
hi, I have no objection as long as the RFC for the release process is adopted before we do any 5.4 releases, as stated earlier, this is the only way to put ourself on the safe side. Cheers, On Thu, Jun 2, 2011 at 10:24 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! We're having pretty lively discussion on the list, twitter and other places, but let's not forget the big goal of 5.4 :) 1. First of all, the official business. Any objections to the RMs for 5.4 being: Stas Malyshev (stas) David Soria Parra (dsp) If not, we'll be the 5.4 RM team. 2. Candidates for 5.4: please review this list: https://wiki.php.net/todo/php54 I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Some of the items are already being discussed, but I'll prepare some kind of official ballot and send to the list soon so we'd have common point. I think it makes sense to have the following limits of the features: a. It should be either obvious how to do it (example: adding E_STRICT to E_ALL), or have full design working patch w/tests or somebody has to commit to doing it within roughly a month term. b. I think we should leave out any big things now, e.g.: annotations - sorry, I know there are many people supporting it, but right now it doesn't seem to be a consensus on how to do it, so I'd rather target 5.5 for it, which if we can make this release go smoothly won't have to be too far out. 3. I'd like to create first alpha sometime next week, if somebody has anything that's not in and wants it in please talk to me. This alpha should in no way be seen as anything stable or final, but rather as a first step on a road to 5.4. -- 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 -- 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] RFC: Short syntax for Arrays (redux)
On Thu, Jun 2, 2011 at 10:19 PM, Sean Coates s...@seancoates.com wrote: If people vote on this now, will further discussion about how this SHOULD work be shut down with we already voted on this? which other discussions do you wish? Json is clearly not an option and not enough people (but a couple) likes or wants it. The RFC is about short array syntax and as far as I can see there is already a clear consensus for one of the proposed new syntax. I don't see why JSON (or JSON-like, or JavaScript Object Literal, or whatever the least politically-fired term of the moment) syntax is clearly not an option. I'm considering writing a new RFC that calls for first-class JSONishy syntax, but I have better things to do if it's already dead in the water. As much as I'd like to avoid drawing out this discussion, I think a premature vote that will be used as a political wedge to shut down all future syntaxes that don't use T_ARRAY is not in the best interest of PHP. You can still vote -1 on this RFC and try to block it. That's the purpose of the votes. But arguing endlessly why json-like syntax is better without an alternative RFC and patch won't bring you anywhere. 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] 5.4 moving forward
Sounds fine to me. On Thu, Jun 2, 2011 at 10:24 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! We're having pretty lively discussion on the list, twitter and other places, but let's not forget the big goal of 5.4 :) 1. First of all, the official business. Any objections to the RMs for 5.4 being: Stas Malyshev (stas) David Soria Parra (dsp) If not, we'll be the 5.4 RM team. 2. Candidates for 5.4: please review this list: https://wiki.php.net/todo/php54 I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Some of the items are already being discussed, but I'll prepare some kind of official ballot and send to the list soon so we'd have common point. I think it makes sense to have the following limits of the features: a. It should be either obvious how to do it (example: adding E_STRICT to E_ALL), or have full design working patch w/tests or somebody has to commit to doing it within roughly a month term. b. I think we should leave out any big things now, e.g.: annotations - sorry, I know there are many people supporting it, but right now it doesn't seem to be a consensus on how to do it, so I'd rather target 5.5 for it, which if we can make this release go smoothly won't have to be too far out. 3. I'd like to create first alpha sometime next week, if somebody has anything that's not in and wants it in please talk to me. This alpha should in no way be seen as anything stable or final, but rather as a first step on a road to 5.4. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Thu, Jun 2, 2011 at 22:24, Stas Malyshev smalys...@sugarcrm.com wrote: I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) You are in general much more likely to get serious reply on this sort of things on the.. mailinglists dedicated for it (php-webmaster@ / systems@). There is just way to much trolling going on on this list for us to be able to read all posts. The wiki code is in svn, so you should be able to commit whatever plugin you need. If you need access to the actual box, ask the technical contact listed on https://wiki.php.net/systems/rl, or systems@ for any other questions. Some of the items are already being discussed, but I'll prepare some kind of official ballot and send to the list soon so we'd have common point. There are still leftovers from the scalar type hint in svn, check zend_do_receive_arg() and zend_do_perform_implementation_check() for example. Please verify you reverted it properly, as these half-reverting is causing segfaults whereas syntax error would be expected. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local PHP docs with search facility
On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote: Could some kind soul advise me on how to install php docs localy and have the excellent patterns search work based on an sqllite database? https://wiki.php.net/doc/phd/view Please ask any followup questions on the proper mailinglist, php...@lists.php.net for questions about the docs, or php-webmas...@lists.php.net for questions about the website. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local PHP docs with search facility
Hannes Magnusson hannes.magnus...@gmail.com writes: On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote: Could some kind soul advise me on how to install php docs localy and have the excellent patterns search work based on an sqllite database? https://wiki.php.net/doc/phd/view Please ask any followup questions on the proper mailinglist, php...@lists.php.net for questions about the docs, or php-webmas...@lists.php.net for questions about the website. Yes, please excuse the wrong group. I realised that after posting. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local PHP docs with search facility
On Jun 2, 2011, at 2:46 PM, Richard Riley wrote: Hannes Magnusson hannes.magnus...@gmail.com writes: On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote: Could some kind soul advise me on how to install php docs localy and have the excellent patterns search work based on an sqllite database? https://wiki.php.net/doc/phd/view Please ask any followup questions on the proper mailinglist, php...@lists.php.net for questions about the docs, or php-webmas...@lists.php.net for questions about the website. Yes, please excuse the wrong group. I realised that after posting. But while we're here, pman is another option: $ pear install phpdocs/pman $ pman mysql_connect That'll show the mysql_connect() documentation as a local man page. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local PHP docs with search facility
On Thu, Jun 2, 2011 at 4:01 PM, Philip Olson phi...@roshambo.org wrote: On Jun 2, 2011, at 2:46 PM, Richard Riley wrote: Hannes Magnusson hannes.magnus...@gmail.com writes: On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote: Could some kind soul advise me on how to install php docs localy and have the excellent patterns search work based on an sqllite database? https://wiki.php.net/doc/phd/view Please ask any followup questions on the proper mailinglist, php...@lists.php.net for questions about the docs, or php-webmas...@lists.php.net for questions about the website. Yes, please excuse the wrong group. I realised that after posting. But while we're here, pman is another option: $ pear install phpdocs/pman $ pman mysql_connect That'll show the mysql_connect() documentation as a local man page. not to shabby ;) and to Richard's question about search the -K option may be just the ticket. -nathan
Re: [PHP-DEV] RFC: Zend Signal Handling
On 02/06/11 18:20, Gustavo Lopes wrote: Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org escreveu: Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch at a time please ;-) And for the record I am all for killing TSRMLS_FETCH. Is there any advantage in killing it as opposed to simply not use it? I think he meant just replacing it in this patch. -- Cheers, Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local PHP docs with search facility
Nathan Nobbe quickshif...@gmail.com writes: On Thu, Jun 2, 2011 at 4:01 PM, Philip Olson phi...@roshambo.org wrote: On Jun 2, 2011, at 2:46 PM, Richard Riley wrote: Hannes Magnusson hannes.magnus...@gmail.com writes: On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote: Could some kind soul advise me on how to install php docs localy and have the excellent patterns search work based on an sqllite database? https://wiki.php.net/doc/phd/view Please ask any followup questions on the proper mailinglist, php...@lists.php.net for questions about the docs, or php-webmas...@lists.php.net for questions about the website. Yes, please excuse the wrong group. I realised that after posting. But while we're here, pman is another option: $ pear install phpdocs/pman $ pman mysql_connect That'll show the mysql_connect() documentation as a local man page. not to shabby ;) and to Richard's question about search the -K option may be just the ticket. -nathan All very nice - thanks for the info. And if anyone has an emacs interface to this please drop me a line . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
State the case for JSON in a separate RFC and progress will be made, but I think there is a fundamental mistake here: serialization formats are the *means* for interoperability, not the ends. The only way I see JSONy syntax would help is if PHP code —with JSONy syntax— would be parsed by a JSON parser, and I don't think that is likely to happen... if you want PHP to have a data structure behave like JSON that is another story. Add use cases, syntax descriptions, and perhaps a patch for this JSON RFC and the main argument will be better understood; an RFC will help, visceral statements and personal attacks, on the other hand, won't, so I bet your time —and everybody else's— will be better spent in writing an RFC to defend it. Regards, David On Thu, Jun 2, 2011 at 4:22 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Jun 2, 2011 at 10:19 PM, Sean Coates s...@seancoates.com wrote: If people vote on this now, will further discussion about how this SHOULD work be shut down with we already voted on this? which other discussions do you wish? Json is clearly not an option and not enough people (but a couple) likes or wants it. The RFC is about short array syntax and as far as I can see there is already a clear consensus for one of the proposed new syntax. I don't see why JSON (or JSON-like, or JavaScript Object Literal, or whatever the least politically-fired term of the moment) syntax is clearly not an option. I'm considering writing a new RFC that calls for first-class JSONishy syntax, but I have better things to do if it's already dead in the water. As much as I'd like to avoid drawing out this discussion, I think a premature vote that will be used as a political wedge to shut down all future syntaxes that don't use T_ARRAY is not in the best interest of PHP. You can still vote -1 on this RFC and try to block it. That's the purpose of the votes. But arguing endlessly why json-like syntax is better without an alternative RFC and patch won't bring you anywhere. 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] RFC: Zend Signal Handling
Hi, 2011/6/2 Michael Maclean mich...@no-surprises.co.uk On 02/06/11 18:20, Gustavo Lopes wrote: Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org escreveu: Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch at a time please ;-) And for the record I am all for killing TSRMLS_FETCH. Is there any advantage in killing it as opposed to simply not use it? I think he meant just replacing it in this patch. Just to inform, with the patched applied in trunk we have 4 SIGSEGVs with ext/pcntl tests: pcntl_alarm() [ext/pcntl/tests/pcntl_alarm.phpt] pcntl_signal() [ext/pcntl/tests/pcntl_signal.phpt] pcnt_signal_dispatch() [ext/pcntl/tests/pcntl_signal_dispatch.phpt] Closures as a signal handler [ext/pcntl/tests/signal_closure_handler.phpt] And 1 test hanging: ext/pcntl/tests/002.phpt -- Regards, Felipe Pena
Re: [PHP-DEV] RFC: Zend Signal Handling
2011/6/2 Felipe Pena felipe...@gmail.com Hi, 2011/6/2 Michael Maclean mich...@no-surprises.co.uk On 02/06/11 18:20, Gustavo Lopes wrote: Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org escreveu: Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch at a time please ;-) And for the record I am all for killing TSRMLS_FETCH. Is there any advantage in killing it as opposed to simply not use it? I think he meant just replacing it in this patch. Just to inform, with the patched applied in trunk we have 4 SIGSEGVs with ext/pcntl tests: pcntl_alarm() [ext/pcntl/tests/pcntl_alarm.phpt] pcntl_signal() [ext/pcntl/tests/pcntl_signal.phpt] pcnt_signal_dispatch() [ext/pcntl/tests/pcntl_signal_dispatch.phpt] Closures as a signal handler [ext/pcntl/tests/signal_closure_handler.phpt] And 1 test hanging: ext/pcntl/tests/002.phpt Ok, already fixed. There is only a test failing due a behavior change: $ cat ext/pcntl/tests/pcntl_signal.diff 009+ Fatal error: Error installing signal handler for -1 in /home/felipe/dev/phptrunk/ext/pcntl/tests/pcntl_signal.php on line 10 009- Warning: pcntl_signal(): Error assigning signal %s 010- bool(false) 011- 012- Warning: pcntl_signal(): Error assigning signal %s 013- bool(false) 014- 015- Warning: pcntl_signal(): not callable is not a callable function name error in %s 016- bool(false) 017- ok -- Regards, Felipe Pena
Re: [PHP-DEV] autoconf 2.60+ support
On 05/15/2011 02:45 AM, Rasmus Lerdorf wrote: As you may have noticed, I have fixed the autoconf stuff to work with autoconf 2.60+ in PHP_5_4 and trunk. In the past I have tried to make it support both 2.60 and =2.60 at the same time and it never worked. autoconf 2.60 was released in June 2006, so nearly 5 years ago and it is in every modern distro at this point. Most distros also have the ability to run older versions concurrently so you should be able to build 5.3 and 5.4 on the same system. On Ubuntu I have to set PHP_AUTOCONF to autoconf2.59 before running ./buildconf in 5.3, for example. With 5.4 you should no longer need to do that. Let me know if there are any autoconf-related problems and we will get them tracked down. -Rasmus Rasmus, We should make PHP 5.4 support autoconf 2.59 by not calling AC_PRESERVE_HELP_ORDER when using autoconf 2.60. This would allow PECL extensions to install on Oracle Linux 5.6 RHEL 5.6 using the standard tool chain. These OSes have autoconf 2.59 without AC_PRESERVE_HELP_ORDER (i.e. autoconf doesn't appear to be 2.59c, see [1]). Currently 'pecl install abc' immediately fails. Anyone on more up to date distros (e.g. Oracle Linux 6.1) will have a autoconf 2.60+ which will support AC_PRESERVE_HELP_ORDER. So there is no functionality lost for most people. On PHP_5_4 I changed the build checks to accept 2.59+ and added ifdefs similar to http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/configure.in?r1=291410r2=291409pathrev=291410 The build seems fine both with the system autoconf 2.59 and a hand built 2.68. There are 'configure --help' order differences between the two, and some new options given when using autoconf 2.68. I think this is acceptable for this edge case. A patch for PHP_5_4 is attached. It drops the overall autoconf requirement to 2.59, allowing both PECL installs and buildconf to work. Chris References: [1] http://lists.gnu.org/archive/html/autoconf/2006-04/msg00085.html -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Index: scripts/phpize.m4 === --- scripts/phpize.m4 (revision 311741) +++ scripts/phpize.m4 (working copy) @@ -1,8 +1,8 @@ dnl This file becomes configure.in for self-contained extensions. -AC_PREREQ(2.60) +AC_PREREQ(2.59) AC_INIT(config.m4) -AC_PRESERVE_HELP_ORDER +ifdef([AC_PRESERVE_HELP_ORDER], [AC_PRESERVE_HELP_ORDER], []) PHP_CONFIG_NICE(config.nice) Index: configure.in === --- configure.in(revision 311741) +++ configure.in(working copy) @@ -8,9 +8,9 @@ dnl Basic autoconf + automake initialization, generation of config.nice. dnl - -AC_PREREQ(2.60) +AC_PREREQ(2.59) AC_INIT(README.SVN-RULES) -AC_PRESERVE_HELP_ORDER +ifdef([AC_PRESERVE_HELP_ORDER], [AC_PRESERVE_HELP_ORDER], []) PHP_CONFIG_NICE(config.nice) Index: build/buildcheck.sh === --- build/buildcheck.sh (revision 311741) +++ build/buildcheck.sh (working copy) @@ -28,18 +28,18 @@ PHP_AUTOCONF='autoconf' fi -# autoconf 2.60 or newer +# autoconf 2.59 or newer ac_version=`$PHP_AUTOCONF --version 2/dev/null|head -n 1|sed -e 's/^[^0-9]*//' -e 's/[a-z]* *$//'` if test -z $ac_version; then echo buildconf: autoconf not found. -echoYou need autoconf version 2.60 or newer installed +echoYou need autoconf version 2.59 or newer installed echoto build PHP from SVN. exit 1 fi IFS=.; set $ac_version; IFS=' ' -if test $1 = 2 -a $2 -lt 60 || test $1 -lt 2; then +if test $1 = 2 -a $2 -lt 59 || test $1 -lt 2; then echo buildconf: autoconf version $ac_version found. -echoYou need autoconf version 2.60 or newer installed +echoYou need autoconf version 2.59 or newer installed echoto build PHP from SVN. exit 1 else -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Object oriented session handlers
Hi, A while ago I submitted a patch to allow session_set_save_handler() to accept a class, and support the inheritance of the default session handler's methods. The RFC has a more detailed description and the current patch: https://wiki.php.net/rfc/session-oo Changes since this was last discussed: - More sanity checking to prevent handlers being called in unexpected states - ZTS fixes Any thoughts? Regards, Arpad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf 2.60+ support
I'm on a plane headed for Rio, so I can't test your patch for a while. If you have checked it on a couple of different systems, commit it, and we will work out any issues during the early stages of getting 5.4 out the door. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local PHP docs with search facility
Hannes Magnusson hannes.magnus...@gmail.com writes: On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote: Could some kind soul advise me on how to install php docs localy and have the excellent patterns search work based on an sqllite database? https://wiki.php.net/doc/phd/view Just as a side note on this informative thread (and to anyone else that comes across it in google), the instructions there dont actually install any of the manual so no look ups / function searches work at all. I'll look into it in more detail later. I'll head over to php...@lists.php.net for further info if thats the correct place. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf 2.60+ support
On 6/2/11 6:44 PM, Rasmus Lerdorf wrote: I'm on a plane headed for Rio, so I can't test your patch for a while. If you have checked it on a couple of different systems, commit it, and we will work out any issues during the early stages of getting 5.4 out the door. -Rasmus I'll test it on Ubuntu and older/newer Oracle Linux stacks, probably on Monday. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
