[PHP-DEV] RFC: Enum
One thing I would really like to see in 5.4 is enums. There is already an RFC for that: https://wiki.php.net/rfc/enum This was discussed in february this year, but no consensus was reached. IIRC, the most notable problems were: - What is the 'value' of enum constant: string or int, user defined scalar, defaults - Ability to make enums more 'class like', some people wanted to be able to add methods. Another thing which was discussed (and I think most people agreed on that), but is not in the RFC: type hinting in method signatures. I think we should keep this simple proposal simple, let it be an enum in all its simplicity. The toughest part would be to decide what would be the default value. Some proposed to use the name of the constant, which is imho best for debuggability (i like this one the best), or an auto incrementing int, saying that it is better performance wise and which is more analog with mysql's enum type. So, to sum up: - Do we really need enum level methods? - Need to reach consensus on default values (strings vs auto inc. ints) - RFC needs to be updated, explaining the type hinting of enums in method signatures Regards, Dennis Haarbrink
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Oops, it was a mistake. I replied to all rather than to the list, so I
apologize because I wanted to give my opinion in general and not to reply to
anybody in particular.
Regards.
2011/6/2 John Crenshaw johncrens...@priacta.com
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.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] [PATCH] Notice on array to string convertion
On Fri, Jun 3, 2011 at 1:05 AM, Arvids Godjuks arvids.godj...@gmail.comwrote: +1 on E_NOTICE 02.06.2011 19:13 пользователь Ilia Alshanetsky i...@prohost.org написал: 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 +1 for E_WARNING Tyrael
[PHP-DEV] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Thu, 2 Jun 2011, Stas Malyshev 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 :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Derick -- 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 Tue, 31 May 2011, Brian Moon wrote: Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem Maas, Hannes Magnusson, David Coallier Still -1. cheers, Derick -- 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 Wed, 1 Jun 2011, Pierre Joye wrote: pls add your svn handle in the right section: https://wiki.php.net/rfc/shortsyntaxforarrays/vote Voting does not belong on some wiki. It belongs here on the mailinglist. Derick -- 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, 2 Jun 2011, David Zülke wrote: Just because the MongoDB developers were stupid enough to build a query language on top of JSON does not mean that JSON or JavaScript object literals need to be supported in PHP. Can't agree more there. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
On Thu, 2 Jun 2011, Ilia Alshanetsky wrote: 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). Yup, E_WARNING sounds best to me too. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
2011/6/3 Derick Rethans der...@php.net: On Thu, 2 Jun 2011, Stas Malyshev 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 :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Why not just to separate voting from participation? I doubt there is somebody that counts all these +1 in the list and tracks progress. I suggest keep voting only in wiki and discussions in ML. Don't have consice opinion yet? Participate ML. Got opinion? Go and vote in the wiki, no need to +1/-1 in the list, it's already too much noise here. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Hi! Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). There will be exposure to the list, with list of topics and explanations. -- 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] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Why doesnt voting happen using a poll/voting engine. Written in (gasp) PHP! (although soon PJSON) On Jun 3, 2011, at 1:03 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). There will be exposure to the list, with list of topics and explanations. -- 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
[PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Fri, 3 Jun 2011, Stas Malyshev wrote: Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. Yes, it's messy on ML. My points where: - a call to vote is easily drowned out on the ML with all the noise - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). And IMO, those two things should be sorted out before we decide to do votes by editting some page on some wiki. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Have you guys considered doodle.com? I think you are all stressing way too much over the voting process. When a vote is closed you can then transfer the decision to the RFC. Drak On 3 June 2011 14:12, Pierre Joye pierre@gmail.com wrote: On Fri, Jun 3, 2011 at 10:22 AM, Derick Rethans der...@php.net wrote: On Fri, 3 Jun 2011, Stas Malyshev wrote: Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. Yes, it's messy on ML. My points where: - a call to vote is easily drowned out on the ML with all the noise - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). There is a log and we know who did edit what. Basic trust is required anyway and if such tricks happen, really, I do not know what to think about the person doing them (well I do, but that's not the place to say it). A plugin will be installed to ease the process, login, vote. You won't be able to add/edit other votes. About when a vote happens and how to inform the devs, I do not see other solutions than getting the devs to read the discussions on the MLs. If some can't stand the heat, then we can't do much for them anyway, 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
[PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Hi! - a call to vote is easily drowned out on the ML with all the noise I read the same ML as you do :) Using threaded email client it is very easy to separate new threads and see calls for votes. Also, voting on ML does not solve the drowning out problem, it makes it worse as about 80% of the people in given vote in a given moment can't say what they are/supposed to be voting for, is discussion still ongoing and what's the consensus, if any. - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). Votes are public, if you see somebody edited it you'd notice. As editing could be done only by admins (if I understand correctly, same guys having root on pretty much all PHP infrastructure) if a plugin is used (see below) I don't think it's a big concern. And IMO, those two things should be sorted out before we decide to do votes by editting some page on some wiki. docuwiki has voting plugins for that purpose, editing some page is not the only way. For example: http://www.dokuwiki.org/plugin:doodle2 -- 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] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
hi Derick, On Fri, Jun 3, 2011 at 9:45 AM, Derick Rethans der...@php.net wrote: On Thu, 2 Jun 2011, Stas Malyshev 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 :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Please re consider your opinion like noises on the list and other similar statements, thanks. As of the votes in the wiki, it is perfectly fine and valid, easy to manage and open. Much more easier than counting random votes in the ML, especially when discussions are split in many threads. The discussions and related activities do happen on the list and that's a good thing. -- 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
[PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Fri, 3 Jun 2011, Stas Malyshev wrote: - a call to vote is easily drowned out on the ML with all the noise I read the same ML as you do :) Using threaded email client it is very easy to separate new threads and see calls for votes. That is subjective. And even with a threaded client, if there are 80+ new messages then the call for vote is drowned out. *Requiring* something like [VOTE] in the subject helps, as then you can set-up a filter. And if it's a requirement, every call without [VOTE] in the subject is invalid. (Easy to fix if somebody forgot it as well). It would expose this kind of thing. Also, voting on ML does not solve the drowning out problem, it makes it worse as about 80% of the people in given vote in a given moment can't say what they are/supposed to be voting for, is discussion still ongoing and what's the consensus, if any. I didn't disagree with this. - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). Votes are public, if you see somebody edited it you'd notice. As editing could be done only by admins (if I understand correctly, same guys having root on pretty much all PHP infrastructure) if a plugin is used (see below) I don't think it's a big concern. And IMO, those two things should be sorted out before we decide to do votes by editting some page on some wiki. docuwiki has voting plugins for that purpose, editing some page is not the only way. For example: http://www.dokuwiki.org/plugin:doodle2 There is no plugin used for it yet, and that's my problem with it. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local PHP docs with search facility
On Fri, Jun 3, 2011 at 00:41, Richard Riley rile...@googlemail.com wrote: 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 . (setq manual-program ./pman) (global-set-key [(f1)] (lambda () (interactive) (manual-entry (current-word That will map F1 to the man page under the current word (thanks to cweiske@). For vi: set keywordprg=pman and then hit shift+k over a function. -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 Fri, Jun 3, 2011 at 06:41, Richard Riley rile...@googlemail.com 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 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 Sure it will. You just need to read the page, which has a very clear requirement. If you can't follow it then http://php.net/mirroring could be a simpler approach for you. -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 Fri, Jun 3, 2011 at 06:41, Richard Riley rile...@googlemail.com 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 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 Sure it will. You just need to read the page, which has a very clear requirement. If you can't follow it then http://php.net/mirroring could be a simpler approach for you. -Hannes I'm not sure it will at all, since they dont show you how to install the phd_php part or inform you that you need to. For a beginner thats a hurdle enough. You are probably too familiar with it to notice this. Result: , | phd -d doc-base/.manual.xml -o output_dir -f php -P PHP ` falls over. Fortunately that was correctly documented elsewhere and was pointed out to me in the php.docs list you recommended. https://doc.php.net/phd/docs/ : installation via pear. Also, I *think*, the instructions there are in addition to mirroring since the mirroring line doesnt include the manual subdir : so both sets are required and you symbolically link to your phpdoc configuration (or so it seems from the instructions). IMO, and with the benefit of being totally new to this and trying to use the docs, It's not clear from the pages if this phpdoc config is in addition to or superceded by the mirroring rsync line. cheers r. -- 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 Fri, Jun 3, 2011 at 12:39, Richard Riley rile...@googlemail.com wrote: Hannes Magnusson hannes.magnus...@gmail.com writes: On Fri, Jun 3, 2011 at 06:41, Richard Riley rile...@googlemail.com 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 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 Sure it will. You just need to read the page, which has a very clear requirement. If you can't follow it then http://php.net/mirroring could be a simpler approach for you. -Hannes I'm not sure it will at all, since they dont show you how to install the phd_php part or inform you that you need to. For a beginner thats a hurdle enough. You are probably too familiar with it to notice this. Result: , | phd -d doc-base/.manual.xml -o output_dir -f php -P PHP ` falls over. Fortunately that was correctly documented elsewhere and was pointed out to me in the php.docs list you recommended. https://doc.php.net/phd/docs/ : installation via pear. Also, I *think*, the instructions there are in addition to mirroring since the mirroring line doesnt include the manual subdir : so both sets are required and you symbolically link to your phpdoc configuration (or so it seems from the instructions). IMO, and with the benefit of being totally new to this and trying to use the docs, It's not clear from the pages if this phpdoc config is in addition to or superceded by the mirroring rsync line. I'd appreciate if you could update the wiki with your experience to help people coming after you -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] autoconf 2.60+ support
I compiled trunk on Ubuntu 11.04 desktop yesterday with default settings and was surprised and confused when it worked even after I forgot to use the older autoconf binary. Nice job! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Local PHP docs with search facility
On Fri, Jun 3, 2011 at 12:56, Richard Riley rile...@googlemail.com wrote: Hannes Magnusson hannes.magnus...@gmail.com writes: On Fri, Jun 3, 2011 at 12:39, Richard Riley rile...@googlemail.com wrote: Hannes Magnusson hannes.magnus...@gmail.com writes: On Fri, Jun 3, 2011 at 06:41, Richard Riley rile...@googlemail.com 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 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 Sure it will. You just need to read the page, which has a very clear requirement. If you can't follow it then http://php.net/mirroring could be a simpler approach for you. -Hannes I'm not sure it will at all, since they dont show you how to install the phd_php part or inform you that you need to. For a beginner thats a hurdle enough. You are probably too familiar with it to notice this. Result: , | phd -d doc-base/.manual.xml -o output_dir -f php -P PHP ` falls over. Fortunately that was correctly documented elsewhere and was pointed out to me in the php.docs list you recommended. https://doc.php.net/phd/docs/ : installation via pear. Also, I *think*, the instructions there are in addition to mirroring since the mirroring line doesnt include the manual subdir : so both sets are required and you symbolically link to your phpdoc configuration (or so it seems from the instructions). IMO, and with the benefit of being totally new to this and trying to use the docs, It's not clear from the pages if this phpdoc config is in addition to or superceded by the mirroring rsync line. I'd appreciate if you could update the wiki with your experience to help people coming after you -Hannes I would love to but dont think its a good idea until I am more familiar - blinded in the headlights, a lot might be me doing the headless chicken routine. I will come back to it at a later date however when I have it working locally and I fully understand the components and the processes. Doing it afterwards will ensure that you forget about it :) Atleast write down your wtfs and todos, so someone can go after you and answer the questions. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Local PHP docs with search facility
Hannes Magnusson hannes.magnus...@gmail.com writes: On Fri, Jun 3, 2011 at 12:56, Richard Riley rile...@googlemail.com wrote: Hannes Magnusson hannes.magnus...@gmail.com writes: On Fri, Jun 3, 2011 at 12:39, Richard Riley rile...@googlemail.com wrote: Hannes Magnusson hannes.magnus...@gmail.com writes: On Fri, Jun 3, 2011 at 06:41, Richard Riley rile...@googlemail.com 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 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 Sure it will. You just need to read the page, which has a very clear requirement. If you can't follow it then http://php.net/mirroring could be a simpler approach for you. -Hannes I'm not sure it will at all, since they dont show you how to install the phd_php part or inform you that you need to. For a beginner thats a hurdle enough. You are probably too familiar with it to notice this. Result: , | phd -d doc-base/.manual.xml -o output_dir -f php -P PHP ` falls over. Fortunately that was correctly documented elsewhere and was pointed out to me in the php.docs list you recommended. https://doc.php.net/phd/docs/ : installation via pear. Also, I *think*, the instructions there are in addition to mirroring since the mirroring line doesnt include the manual subdir : so both sets are required and you symbolically link to your phpdoc configuration (or so it seems from the instructions). IMO, and with the benefit of being totally new to this and trying to use the docs, It's not clear from the pages if this phpdoc config is in addition to or superceded by the mirroring rsync line. I'd appreciate if you could update the wiki with your experience to help people coming after you -Hannes I would love to but dont think its a good idea until I am more familiar - blinded in the headlights, a lot might be me doing the headless chicken routine. I will come back to it at a later date however when I have it working locally and I fully understand the components and the processes. Doing it afterwards will ensure that you forget about it :) Atleast write down your wtfs and todos, so someone can go after you and answer the questions. -Hannes Yes Dad ... ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Enum
On 3 June 2011 08:26, Dennis Haarbrink dhaarbr...@gmail.com wrote:
So, to sum up:
- Do we really need enum level methods?
- Need to reach consensus on default values (strings vs auto inc. ints)
- RFC needs to be updated, explaining the type hinting of enums in method
signatures
I'm wondering if the enum storage would work like an array.
The parallel ...
array('YES', 'NO', 'MAYBE') vs. enum{YES, NO, MAYBE}
In this example, all the keys of the array would be the same as the
values of the enum
array(0 = 'YES', 1 = 'NO', 2 = 'MAYBE') vs. enum(YES = 0, NO = 1, MAYBE = 2}
In both cases, there is a name/value pairing. In both cases an
unassigned key (for the array) or value (for the enum) is
automatically determined.
If a non sequential integer value is used ...
array(2047 = 'E_ALL_PRE_5_2', 6143 = 'E_ALL_5_2', 30719 =
'E_ALL_5_3') vs enum{E_ALL_PRE_5_2 = 2047, E_ALL_5_2 = 6143, E_ALL_5_3
= 30719}
then this still follows a recognisable pattern of key/value.
If a non numeric key(array) or value(enum) is used, then I think the
enum{} should follow the existing array() rules.
If a mix is used, then there is already a well documented pattern of
behaviour that I think should be followed.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
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 Ilia Alshanetsky i...@prohost.org:
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).
My initial choice for E_NOTICE was based on _convert_to_string() which
already used the E_NOTICE level.
E_WARNING could make sense too, but I have the feeling that this
should be part of a bigger review concerning E_NOTICE/E_WARNING errors
related to conversion to be as much coherent as possible.
Find below a short list of zend_error() calls made from bad conversion:
Zend/zend.c:
ZEND_API void zend_make_printable_zval(zval *expr, zval *expr_copy,
int *use_copy) /* {{{ */
282:zend_error(EG(exception) ? E_ERROR : E_RECOVERABLE_ERROR, Object
of class %s could not be converted to string, Z_OBJCE_P(expr)-name);
Zend/zend_object_handlers.c:
ZEND_API int zend_std_cast_object_tostring(zval *readobj, zval
*writeobj, int type TSRMLS_DC) /* {{{ */
1508:zend_error(E_NOTICE, Object of class %s could not be converted
to int, ce-name);
1517:zend_error(E_NOTICE, Object of class %s could not be converted
to double, ce-name);
Zend/zend_operators.c:
ZEND_API void convert_scalar_to_number(zval *op TSRMLS_DC) /* {{{ */
244:zend_error(E_WARNING, Cannot convert to ordinal value); \
ZEND_API void convert_to_long_base(zval *op, int base) /* {{{ */
375:zend_error(E_NOTICE, Object of class %s could not be converted to
int, Z_OBJCE_P(op)-name);
382:zend_error(E_WARNING, Cannot convert to ordinal value);
ZEND_API void convert_to_double(zval *op) /* {{{ */
435:zend_error(E_NOTICE, Object of class %s could not be converted to
double, Z_OBJCE_P(op)-name);
442:zend_error(E_WARNING, Cannot convert to real value (type=%d),
Z_TYPE_P(op));
ZEND_API void _convert_to_string(zval *op ZEND_FILE_LINE_DC) /* {{{ */
580:zend_error(E_NOTICE, Array to string conversion);
594:zend_error(E_NOTICE, Object of class %s to string conversion,
Z_OBJCE_P(op)-name);
As you can notice ;) this is not uniformly handled, however, many of
those line does not appear to be reachable according to
http://gcov.php.net/. There is room for a general improvement here.
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Enum
Hi, The RFC was supposed to be a draft (i didn't really added it in the good section) and was written more to introduce the idea and make people think about it. Feel free to update it with any idea, concern you may have. Pierrick On 3 June 2011 03:26, Dennis Haarbrink dhaarbr...@gmail.com wrote: One thing I would really like to see in 5.4 is enums. There is already an RFC for that: https://wiki.php.net/rfc/enum This was discussed in february this year, but no consensus was reached. IIRC, the most notable problems were: - What is the 'value' of enum constant: string or int, user defined scalar, defaults - Ability to make enums more 'class like', some people wanted to be able to add methods. Another thing which was discussed (and I think most people agreed on that), but is not in the RFC: type hinting in method signatures. I think we should keep this simple proposal simple, let it be an enum in all its simplicity. The toughest part would be to decide what would be the default value. Some proposed to use the name of the constant, which is imho best for debuggability (i like this one the best), or an auto incrementing int, saying that it is better performance wise and which is more analog with mysql's enum type. So, to sum up: - Do we really need enum level methods? - Need to reach consensus on default values (strings vs auto inc. ints) - RFC needs to be updated, explaining the type hinting of enums in method signatures Regards, Dennis Haarbrink
Re: [PHP-DEV] RFC: Enum
As soon as I have my requested write permission in the rfc namespace i will update it. -- Dennis Haarbrink 2011/6/3 Pierrick Charron pierr...@webstart.fr Hi, The RFC was supposed to be a draft (i didn't really added it in the good section) and was written more to introduce the idea and make people think about it. Feel free to update it with any idea, concern you may have. Pierrick On 3 June 2011 03:26, Dennis Haarbrink dhaarbr...@gmail.com wrote: One thing I would really like to see in 5.4 is enums. There is already an RFC for that: https://wiki.php.net/rfc/enum This was discussed in february this year, but no consensus was reached. IIRC, the most notable problems were: - What is the 'value' of enum constant: string or int, user defined scalar, defaults - Ability to make enums more 'class like', some people wanted to be able to add methods. Another thing which was discussed (and I think most people agreed on that), but is not in the RFC: type hinting in method signatures. I think we should keep this simple proposal simple, let it be an enum in all its simplicity. The toughest part would be to decide what would be the default value. Some proposed to use the name of the constant, which is imho best for debuggability (i like this one the best), or an auto incrementing int, saying that it is better performance wise and which is more analog with mysql's enum type. So, to sum up: - Do we really need enum level methods? - Need to reach consensus on default values (strings vs auto inc. ints) - RFC needs to be updated, explaining the type hinting of enums in method signatures Regards, Dennis Haarbrink
Re: [PHP-DEV] RFC: Enum
On 6/3/2011 8:27 AM, Dennis Haarbrink wrote: As soon as I have my requested write permission in the rfc namespace i will update it. -- Dennis Haarbrink 2011/6/3 Pierrick Charronpierr...@webstart.fr Hi, The RFC was supposed to be a draft (i didn't really added it in the good section) and was written more to introduce the idea and make people think about it. Feel free to update it with any idea, concern you may have. Pierrick On 3 June 2011 03:26, Dennis Haarbrinkdhaarbr...@gmail.com wrote: One thing I would really like to see in 5.4 is enums. There is already an RFC for that: https://wiki.php.net/rfc/enum This was discussed in february this year, but no consensus was reached. IIRC, the most notable problems were: - What is the 'value' of enum constant: string or int, user defined scalar, defaults - Ability to make enums more 'class like', some people wanted to be able to add methods. Another thing which was discussed (and I think most people agreed on that), but is not in the RFC: type hinting in method signatures. I think we should keep this simple proposal simple, let it be an enum in all its simplicity. The toughest part would be to decide what would be the default value. Some proposed to use the name of the constant, which is imho best for debuggability (i like this one the best), or an auto incrementing int, saying that it is better performance wise and which is more analog with mysql's enum type. So, to sum up: - Do we really need enum level methods? - Need to reach consensus on default values (strings vs auto inc. ints) - RFC needs to be updated, explaining the type hinting of enums in method signatures Regards, Dennis Haarbrink If I might raise the question, I am also really interested in how enums could respond across namespace. Personally, I am not entirely sure about the ability to add methods to enums. That sounds like a class, to me. However, the second example on the RFC of use-case, wherein the developer uses a class to contain constants, sounds to me like a namespacing issue. Would enums be objects that are within the scope of the namespace, like classes, or would they be global? I would personally favor they remain in the scope of the namespace. That removes the need to prefix them with any sort of pseudo-namespace (like a class, for example), and it prevents collisions, of course. - M. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Martin Scotta On Fri, Jun 3, 2011 at 5:16 AM, Pierre Joye pierre@gmail.com wrote: hi Derick, On Fri, Jun 3, 2011 at 9:45 AM, Derick Rethans der...@php.net wrote: On Thu, 2 Jun 2011, Stas Malyshev 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 :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Please re consider your opinion like noises on the list and other similar statements, thanks. As of the votes in the wiki, it is perfectly fine and valid, easy to manage and open. Much more easier than counting random votes in the ML, especially when discussions are split in many threads. The discussions and related activities do happen on the list and that's a good thing. Yes, but only who has wiki karma are allowed to vote. -- 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] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
How about a separate email topic dedicated to voting?, that would reduce the signal to noise ratio for votes (and increase it for opinions). Regards, David On Fri, Jun 3, 2011 at 10:25 AM, Martin Scotta martinsco...@gmail.comwrote: Martin Scotta On Fri, Jun 3, 2011 at 5:16 AM, Pierre Joye pierre@gmail.com wrote: hi Derick, On Fri, Jun 3, 2011 at 9:45 AM, Derick Rethans der...@php.net wrote: On Thu, 2 Jun 2011, Stas Malyshev 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 :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Please re consider your opinion like noises on the list and other similar statements, thanks. As of the votes in the wiki, it is perfectly fine and valid, easy to manage and open. Much more easier than counting random votes in the ML, especially when discussions are split in many threads. The discussions and related activities do happen on the list and that's a good thing. Yes, but only who has wiki karma are allowed to vote. -- 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
The crash is now fixed as well. On Fri, Jun 3, 2011 at 2:41 AM, Felipe Pena felipe...@gmail.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Enum
As much as I used enums in C++, I'm not sure that this is really the right tool here, and it often introduces more problems than it solves. Specific concerns that come to mind: 1. In C++ this often led to nasty needs such as a LOG_LEVEL_COUNT entry at the end of the list of enums. 2. Sometimes devs want to add items in the middle of the list for code organization purposes. This silently changes the values of the other constants and it isn't clear when that will or won't break stuff. 3. Better than half the time, enums seem to be a series of bit flags, not sequential numbers (in this case enum offers NO value over the current const lists). 4. The greatest value of enums in C++ is actually related to typesafety. Admittedly, this was sometimes more of a frustration than a help, but that was really just an implementation issue, not an inherent problem with enums and typesafety. 5. There is no clear path for extending the enums through inheritance. Allowing enums to be (optionally) named would open a clear path to address counts and hinting, but still doesn't address the problems inherent in automatic numbering, and would complicate the inheritance question. IMHO this should wait until we can address some of these items. Otherwise the feature is just a halfbaked not-so-short shorthand for constants. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Enum
2011/6/3 Marcel Esser marcel.es...@croscon.com On 6/3/2011 8:27 AM, Dennis Haarbrink wrote: As soon as I have my requested write permission in the rfc namespace i will update it. -- Dennis Haarbrink 2011/6/3 Pierrick Charronpierr...@webstart.fr Hi, The RFC was supposed to be a draft (i didn't really added it in the good section) and was written more to introduce the idea and make people think about it. Feel free to update it with any idea, concern you may have. Pierrick On 3 June 2011 03:26, Dennis Haarbrinkdhaarbr...@gmail.com wrote: One thing I would really like to see in 5.4 is enums. There is already an RFC for that: https://wiki.php.net/rfc/enum This was discussed in february this year, but no consensus was reached. IIRC, the most notable problems were: - What is the 'value' of enum constant: string or int, user defined scalar, defaults - Ability to make enums more 'class like', some people wanted to be able to add methods. Another thing which was discussed (and I think most people agreed on that), but is not in the RFC: type hinting in method signatures. I think we should keep this simple proposal simple, let it be an enum in all its simplicity. The toughest part would be to decide what would be the default value. Some proposed to use the name of the constant, which is imho best for debuggability (i like this one the best), or an auto incrementing int, saying that it is better performance wise and which is more analog with mysql's enum type. So, to sum up: - Do we really need enum level methods? - Need to reach consensus on default values (strings vs auto inc. ints) - RFC needs to be updated, explaining the type hinting of enums in method signatures Regards, Dennis Haarbrink If I might raise the question, I am also really interested in how enums could respond across namespace. Personally, I am not entirely sure about the ability to add methods to enums. That sounds like a class, to me. However, the second example on the RFC of use-case, wherein the developer uses a class to contain constants, sounds to me like a namespacing issue. Would enums be objects that are within the scope of the namespace, like classes, or would they be global? I would personally favor they remain in the scope of the namespace. That removes the need to prefix them with any sort of pseudo-namespace (like a class, for example), and it prevents collisions, of course. - M. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I'm also not so sure about inlining an enum in a class. I think they should always be first class citizens. And as such they adhere to the same namespace rules as classes. Maybe Pierrick can clarify his intentions. -- Dennis Haarbrink
Re: [PHP-DEV] RFC: Enum
2011/6/3 John Crenshaw johncrens...@priacta.com As much as I used enums in C++, I'm not sure that this is really the right tool here, and it often introduces more problems than it solves. Specific concerns that come to mind: 1. In C++ this often led to nasty needs such as a LOG_LEVEL_COUNT entry at the end of the list of enums. 2. Sometimes devs want to add items in the middle of the list for code organization purposes. This silently changes the values of the other constants and it isn't clear when that will or won't break stuff. 3. Better than half the time, enums seem to be a series of bit flags, not sequential numbers (in this case enum offers NO value over the current const lists). 4. The greatest value of enums in C++ is actually related to typesafety. Admittedly, this was sometimes more of a frustration than a help, but that was really just an implementation issue, not an inherent problem with enums and typesafety. 5. There is no clear path for extending the enums through inheritance. Allowing enums to be (optionally) named would open a clear path to address counts and hinting, but still doesn't address the problems inherent in automatic numbering, and would complicate the inheritance question. IMHO this should wait until we can address some of these items. Otherwise the feature is just a halfbaked not-so-short shorthand for constants. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 1. I'm not so sure what you mean with that statement 2. A very strong argument for using the name of the constant as the default value 3 and 4: The way I see it, type safety is the *only* valid argument for proposing enums 5: I have never felt the need for inheritance in enums. Do you have a use case for that? I also think that enums should always be named. -- Dennis Haarbrink
RE: [PHP-DEV] RFC: Enum
1. Yeah, let me explain: A lot of times (at least in the patterns that
lead to enum usage in C++) you need to be able to know what is in the enum, for
example, to iterate a list that will have exactly the same number of entries as
the enum or something. In other words, the enum represents something, and often
times you need to enumerate the enum. In C++, the only DRY way to do this is
to add a *_COUNT entry as the last enum, which will conveniently result in
that entry getting assigned a value equal to the number of entries, so you can
do something like for(int i = 0; i FOO_COUNT; i++) {}. I can't say for sure
that we will or won't run into this in PHP, but the nature of enums makes these
sorts of patters likely. The fix (I think) is to be able to inspect the enum.
Probably need to support count(enumtype), as well as something like
enum_ids(enumtype), enum_values(enumtype), and enum_to_array(enumtype).
2. True, name as value is the only solution I see for that, but this
would make the behavior radically different from the likely expectation.
Sometimes it doesn't matter, but sometimes it will. I have some concern with
something that LOOKS like an enum from other languages where enums are
integral, but doesn't actually act integral. The other problem with
non-integral enums is comparison, which users might expect to work by default.
Unless this was implemented as a whole new type internally, comparison would be
impossible. Implementing as a new type raises questions about implicit
conversion, so that probably won't work.
5. This is heavily connected to the typesafety question. A simple
potential PHP example that comes to mind would be the Zend_Log class. This
class has a list of priorities, which would make a whole lot of sense to put in
an enum. (Incidentally an enum_to_array() method would then allow this code
to be cleaned up a bit). The log method accepts priority as an argument, so it
would be sensible to give this a type hint. The catch is that the class is also
designed to allow new priorities to be added later, especially in a derived
class, so, I derive a new My_Log class, and want to extend the enum with a
couple of additional entries. (I actually worked with some code almost exactly
like this just a few days ago). The bottom line here is that enums become a
hinderance to inheritance unless they can be extended. If an enum can't be
extended, it is effectively final, regardless of whether that is actually
helpful.
John Crenshaw
Priacta, Inc.
From: Dennis Haarbrink [mailto:dhaarbr...@gmail.com]
Sent: Friday, June 03, 2011 2:37 PM
To: John Crenshaw
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Enum
2011/6/3 John Crenshaw
johncrens...@priacta.commailto:johncrens...@priacta.com
As much as I used enums in C++, I'm not sure that this is really the right tool
here, and it often introduces more problems than it solves. Specific concerns
that come to mind:
1. In C++ this often led to nasty needs such as a LOG_LEVEL_COUNT entry at
the end of the list of enums.
2. Sometimes devs want to add items in the middle of the list for code
organization purposes. This silently changes the values of the other constants
and it isn't clear when that will or won't break stuff.
3. Better than half the time, enums seem to be a series of bit flags, not
sequential numbers (in this case enum offers NO value over the current const
lists).
4. The greatest value of enums in C++ is actually related to typesafety.
Admittedly, this was sometimes more of a frustration than a help, but that was
really just an implementation issue, not an inherent problem with enums and
typesafety.
5. There is no clear path for extending the enums through inheritance.
Allowing enums to be (optionally) named would open a clear path to address
counts and hinting, but still doesn't address the problems inherent in
automatic numbering, and would complicate the inheritance question.
IMHO this should wait until we can address some of these items. Otherwise the
feature is just a halfbaked not-so-short shorthand for constants.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
1. I'm not so sure what you mean with that statement
2. A very strong argument for using the name of the constant as the default
value
3 and 4: The way I see it, type safety is the *only* valid argument for
proposing enums
5: I have never felt the need for inheritance in enums. Do you have a use case
for that?
I also think that enums should always be named.
--
Dennis Haarbrink
Re: [PHP-DEV] DOMNode::getAttribute()
Does anyone know of a particular reason it is not documented? (I'd be happy to document and provide the ridiculously simple patch of returning NULL...) Greetings Matt, Documenting DOM is messy/tricky (and underdocumented), but: - http://php.net/domelement.getattribute Here's one option to begin helping out with the PHP documentation: - https://edit.php.net/ And please write php...@lists.php.net for additional documentation related details and/or questions. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOMNode::getAttribute()
On Jun 3, 2011, at 1:38 PM, Matt Pelmear wrote:
Hello,
I discovered today that the DOMNode::getAttribute() function (which is
undocumented on the php site) returns an empty string if the requested
attribute doesn't exist in the node.
From the source:
if (value == NULL) {
RETURN_EMPTY_STRING();
} else {
RETVAL_STRING((char *)value, 1);
xmlFree(value);
}
Seems to me that it should return NULL. (That's what libxml does, apparently.)
Does anyone know of a particular reason it returns an empty string instead?
Does anyone know of a particular reason it is not documented?
(I'd be happy to document and provide the ridiculously simple patch of
returning NULL...)
We match the behaviour the w3c defines for the DOM.
DOMString
The Attr value as a string, or the empty string if that attribute does not have
a specified or default value.
Consider using hasAttribute() if you care about the existence.
- Scott
--
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)
It's not FUD.
It is different from writing json_decode('ä\u0123'), because json_decode() in
PHP only accepts UTF-8 encoded input;
Give it a shot:
?php
$chr = \xC3\xA4; // ä as UTF-8
var_dump(json_decode('[' . $chr . '\u00e4]'));
var_dump(json_decode('[' . utf8_decode($chr) . '\u00e4]'));
?
That'll produce:
array(1) {
[0]=
string(4) ää
}
NULL
Understand what the problem is now?
If someone does this in a latin1-encoded file:
?php $fancyNewArray = {yay: ä}; ?
Then that is valid as a PHP array (as it's a latin1 ä, so \xE4), but cannot
be consumed by PHP's json_decode(). And that would be terribly inconsistent
behavior.
David
On 02.06.2011, at 22:15, Andrei Zmievski wrote:
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
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] DOMNode::getAttribute()
On 03.06.2011, at 22:38, Matt Pelmear wrote: Hello, I discovered today that the DOMNode::getAttribute() function (which is undocumented on the php site) It's DOMElement::getAttribute()... returns an empty string if the requested attribute doesn't exist in the node. Yes, but that's in line with the W3C DOM spec! David smime.p7s Description: S/MIME cryptographic signature
[PHP-DEV] JSON array/object syntax
Hi,
After reading all the debate in the other thread it is still not clear to me
what the real advantages are of adopting JSON syntax for native PHP
types. Doing json_encode to an object and expect the code and output to be
the same seems useless to me, and reading David Zülke's example it seems
more like a pure-unicode issue to me:
It is different from writing json_decode('ä\u0123'), because json_decode()
in PHP only accepts UTF-8 encoded input;
Give it a shot:
?php
$chr = \xC3\xA4; // ä as UTF-8
var_dump(json_decode('[' . $chr . '\u00e4]'));
var_dump(json_decode('[' . utf8_decode($chr) . '\u00e4]'));
?
That'll produce:
array(1) {
[0]=
string(4) ää
}
NULL
Understand what the problem is now?
If someone does this in a latin1-encoded file:
?php $fancyNewArray = {yay: ä}; ?
Then that is valid as a PHP array (as it's a latin1 ä, so \xE4), but
cannot be consumed by PHP's json_decode(). And that would be terribly
inconsistent behavior.
-
It looks more like you want to do json_decode to PHP code hoping that will
somehow fix json_decode... instead of fixing json_decode.
Could someone advocating this please explain with use-cases and concrete
punctualized examples the advantages of having such JSON approach to PHP.
Regards,
David Vega
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Hi! That is subjective. And even with a threaded client, if there are 80+ new messages then the call for vote is drowned out. *Requiring* There was never 80+ new messages on different topics on the list. There are 3-4 topics max, if you not count commit messages. Each of them can contain dozens of messages, but those can be easily grouped. something like [VOTE] in the subject helps, as then you can set-up a [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. -- 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 Fri, Jun 3, 2011 at 3:11 PM, David Zülke
david.zue...@bitextender.com wrote:
It's not FUD.
It is different from writing json_decode('ä\u0123'), because json_decode() in
PHP only accepts UTF-8 encoded input;
Give it a shot:
?php
$chr = \xC3\xA4; // ä as UTF-8
var_dump(json_decode('[' . $chr . '\u00e4]'));
var_dump(json_decode('[' . utf8_decode($chr) . '\u00e4]'));
?
That'll produce:
array(1) {
[0]=
string(4) ää
}
NULL
Understand what the problem is now?
If someone does this in a latin1-encoded file:
?php $fancyNewArray = {yay: ä}; ?
Then that is valid as a PHP array (as it's a latin1 ä, so \xE4), but cannot
be consumed by PHP's json_decode(). And that would be terribly inconsistent
behavior.
David
Of course I know how json_decode() works, David. My question back to
you is, do you know how a parser works? Because there's no reason to
invoke json_decode() on $fancyNewArray, since it would already be an
object, constructed by the Zend parser. The handling of the characters
in the key/value strings is exactly the same as in normal object
property assignments.
-Andrei
P.S. Stop being so patronizing.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
