Re: [PHP-DEV] Generators in PHP
I too don't think that a new keyword is necessary for this case. Let's
not forget that it is a common practice to document functions with doc
blocks, which further helps understanding what it does.
/**
* @return Generator
* @yield string
*/
function generate() {
...
yield $foo;
...
}
Cheers,
Bernhard
2012/7/26 Alex Aulbach alex.aulb...@gmail.com:
2012/7/26 Yahav Gindi Bar g.b.ya...@gmail.com:
yielder sounds quite weird don't you think (but my native language is not
English too.. so don't blame me at english stupid conclusions!)
Fact: generator is not a good keyword, because too common.
I can't see the connection... people relate the generator keyword to the
iterators so what's the problem using it?
PHP will just complain in existing scripts if you use generator as
function-name and stops compiling. I think this is stupid, but that's
a completly different discussion.
what about using the iterator name as generators keyword? because it does
return iterators...
well, wouldn't think, that it can be that easy.
iterator foo() { ... yield $bar; ... } sounds OK for me... and got a meaning
too.
though it can confuse some people with the original iterators...
But it's just what it does.
BTW: I still don't think that the generators need a unique word and I
suggest using functions, but I didn't read al the mails chain, so I assume
that I'll find there the answer.
Of course you will!
making gesturesThese are not the droids your looking for. Ups. wrong line.
:)
--
Alex Aulbach
--
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] RFCs and organisation
Hi! Secondly, I noticed that Python's PEPs are numbered, unlike PHP's RFCs. Whilst they aren't quite the same thing, I wonder if this would be useful, particularly since it provides a simple and unambiguous way to refer to one, e.g. RFC 123 instead of RFC on how to write an RFC. Why have numbers if we can use URLs? URLs both uniquely identify the RFC and suggest what they are about. Can you say what PEP 410 is about? How about https://wiki.php.net/rfc/releaseprocess? If we do that, we should call them PHP RFCs (PRFCs?) instead, to avoid confusion with IETF RFCs, otherwise it may get confusing. I have yet to meet one person who was confused when we talked about generators RFC and thought we meant IETF RFC describing standards for electrical generators in data centers. -- 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] RFCs and organisation
Stas Malyshev wrote: Why have numbers if we can use URLs? URLs both uniquely identify the RFC and suggest what they are about. Can you say what PEP 410 is about? How about https://wiki.php.net/rfc/releaseprocess? That sounds way better, agreed. I have yet to meet one person who was confused when we talked about generators RFC and thought we meant IETF RFC describing standards for electrical generators in data centers. I meant more with regards to numbered RFCs. -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFCs and organisation
Hi Andrew: On 25 Jul 2012, at 22:50, Andrew Faulds wrote: I think someone (perhaps me) should write an RFC on how to write an RFC Note that a new page create on the wiki in the RFC namespace comes with a template that gives some guidance on how to write an RFC. Lukas based it on my original Traits RFC, since that one was considered to be a nice example. At least it was kind of complete with regard to the essential parts of an RFC: - intro - motivation - full description (up-to-date following the discussions) of the proposed feature - with examples and use cases - summary of semantics - a patch And then based on discussion: - FAQ or common misconceptions - alternative proposals - rejected features - change log Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFCs and organisation
Hi Stefan, I made an RFC page on it. http://wiki.php.net/rfc/howto It's not really an RFC, more a meta-RFC or informational wiki page. It would helpful if you could edit it too. I just want to make an obvious go-to place for info on this. Thanks. On 26/07/12 08:49, Stefan Marr wrote: Hi Andrew: On 25 Jul 2012, at 22:50, Andrew Faulds wrote: I think someone (perhaps me) should write an RFC on how to write an RFC Note that a new page create on the wiki in the RFC namespace comes with a template that gives some guidance on how to write an RFC. Lukas based it on my original Traits RFC, since that one was considered to be a nice example. At least it was kind of complete with regard to the essential parts of an RFC: - intro - motivation - full description (up-to-date following the discussions) of the proposed feature - with examples and use cases - summary of semantics - a patch And then based on discussion: - FAQ or common misconceptions - alternative proposals - rejected features - change log Best regards Stefan -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Supports 'finally' keyword for PHP exceptions
Hi all: Here are a test script lists, which I think could be help to understand the current implemented behaviors: try..catch..finally https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_001.phpt https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_002.phpt https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_003.phpt https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_004.phpt https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_005.phpt https://github.com/laruence/php-src/blob/finally/Zend/tests/catch_finally_006.phpt try...finally https://github.com/laruence/php-src/blob/finally/Zend/tests/try_finally_001.phpt https://github.com/laruence/php-src/blob/finally/Zend/tests/try_finally_002.phpt https://github.com/laruence/php-src/blob/finally/Zend/tests/try_finally_003.phpt thanks On Tue, Jul 24, 2012 at 7:20 PM, Laruence larue...@php.net wrote: Hi: As the previous threads disscussed, I make a implemention. here is the RFC: https://wiki.php.net/rfc/finally any suggestions? thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFCs and organisation
On 07/26/2012 11:41 AM, Andrew Faulds wrote: Hi Stefan, I made an RFC page on it. http://wiki.php.net/rfc/howto It's not really an RFC, more a meta-RFC or informational wiki page. It would helpful if you could edit it too. I just want to make an obvious go-to place for info on this. What I see as most in need of upgrade would be an automatic Table of Contents on the RFC page itself - with RFCs sorted by status. There have been numerous cases of people forgetting to put their new RFC on the index page, not updating to voting etc.pp Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ReflectionParameter::getClassName() missing
I was doing some work with the Reflection API, and I ran into something missing from ReflectionParameter. Turns out, there's no way to get the class-name of a parameter, short of calling getClass() - the problem with that is, there's no way to get the class-name of a parameter without causing the class itself to autoload. Okay, so I can work around that by __toString() and parsing that, but that seems rather hacky. Thoughts?
Re: [PHP-DEV] RFCs and organisation
Florian Anderiasch wrote: I made an RFC page on it.http://wiki.php.net/rfc/howto It's not really an RFC, more a meta-RFC or informational wiki page. It would helpful if you could edit it too. I just want to make an obvious go-to place for info on this. What I see as most in need of upgrade would be an automatic Table of Contents on the RFC page itself - with RFCs sorted by status. There have been numerous cases of people forgetting to put their new RFC on the index page, not updating to voting etc.pp There was a time when one could have written an app for it in PHP ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
On Wed, Jul 25, 2012 at 11:00 PM, Jared Williams jared.willia...@ntlworld.com wrote: Though here is seemingly another problem, though it could be within spl's MultipleIterator() Thanks, this is fixed now (see https://github.com/nikic/php-src/commit/268740d9848d435054ce73a8cfe36b2b732cd1f7). It turned out that you have to implement the Iterator interface before assigning the get_iterator handler. Again, thanks for testing the patch and providing useful feedback :) Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Release Frequency, NEWS, etc.
Hi, since 5.4.0 was released on March 1st we had 6 releases for 5.3 and 5.4 Basically following the mandate At least one release per month, more at wish from the release process RFC[1] with some additional emergency releases in between. The synchrony between those two means that currently 5.3 is nice 10 releases ahead (5.3.15 and 5.4.5 were released together, 5.3.14 and 5.4.4 were etc.). This is nice as you can easily guess that a fix in 5.3.13 will be in 5.4.3, too. Now such a fast, monthly cycle might be good for 5.4 but for 5.3 I think we should slow it down. In my opinion we should try to promote 5.4 over 5.3, give mit more exclusive visibility. People who stay on 5.3 expect to have a stable foundation, and aren't eager to check whether an update is relevant to them that often, especially as most (all?) things fixed in 5.3 are bugs which exist for a few years already. My expectation therefore is that users spend less attention on these and therefore miss critical fixes. I would therefore like to reduce the 5.3 pace. The current idea would be to skip every second release (unless security issues demand something else) both in release date as well as version number. So for instance 5.4.6 will be released sometime next month alone. A month later there will be 5.3.17 and 5.4.7. Doing this has an obvious issue, though: NEWS entries are currently only placed in the lowest branch. With the example from above and the current way the NEWS are handled 5.4.6 NEWS would be quite small and there would be no 5.3 NEWS to check for further things. Any comments on the general idea or suggestions for the NEWS thing? johannes [1] https://wiki.php.net/rfc/releaseprocess -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFCs and organisation
There was a time when one could have written an app for it in PHP ;) Right. We all know from the beginning that a wiki is better than nothing but, when the number of users/documents grows, it becomes very hard to keep the information up-to-date. Another problem is that documents and their comments are not stored together. The RFC remains, which is fine, but the comments fly away, except if the author manually copies them from the list. IMHO, this is the main drawback of the current system: when I read an RFC, I also want to read the comments because they're an integral part of the RFC life. It does not mean that they should not be mirrored to the mailing list, but it is essential to store them with the RFC. Maybe it is time to replace the wiki with a real RFC app. Thoughts ? Do you know of an existing app used by a similar development community ? If not, what would you build it from ? Who would be ready to participate ? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFCs and organisation
On 26/07/12 16:44, Laupretre François wrote: There was a time when one could have written an app for it in PHP ;) Right. We all know from the beginning that a wiki is better than nothing but, when the number of users/documents grows, it becomes very hard to keep the information up-to-date. Another problem is that documents and their comments are not stored together. The RFC remains, which is fine, but the comments fly away, except if the author manually copies them from the list. IMHO, this is the main drawback of the current system: when I read an RFC, I also want to read the comments because they're an integral part of the RFC life. It does not mean that they should not be mirrored to the mailing list, but it is essential to store them with the RFC. Maybe it is time to replace the wiki with a real RFC app. Thoughts ? Do you know of an existing app used by a similar development community ? If not, what would you build it from ? Who would be ready to participate ? Regards François Hi, Writing an RFC app doesn't strike me as terribly difficult. We already have the VCS/wiki authentication system, so we can use that. Then we just need some formatting language (DokuWiki's if separable, else I'd suggest Markdown), or no formatting language (plain text), and a flat-file or DB storage system (would prefer the former personally). I'd be willing to write one, although I'm away next week. But I could work on it today and tommorow. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Release Frequency, NEWS, etc.
Hi! The current idea would be to skip every second release (unless security issues demand something else) both in release date as well as version number. So for instance 5.4.6 will be released sometime next month alone. A month later there will be 5.3.17 and 5.4.7. I think it makes sense. Doing this has an obvious issue, though: NEWS entries are currently only placed in the lowest branch. With the example from above and the current way the NEWS are handled 5.4.6 NEWS would be quite small and there would be no 5.3 NEWS to check for further things. I think note in the NEWS should be placed immediately when the bug is fixed (at least the lowest version NEWS). However, if we want the bug to appear in all NEWS for both 5.4 and 5.3, I think we'd have to ask people to put note in both. I, on my part, am reviewing NEWS periodically and merge entries that I can find that are in 5.3 but not in 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] Release Frequency, NEWS, etc.
On Thu, Jul 26, 2012 at 9:41 AM, Johannes Schlüter johan...@schlueters.de wrote: I would therefore like to reduce the 5.3 pace. I like this idea as well. I think the 5.3.x series also benefits from reducing the pace because it has fewer chances to introduce new bugs. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFCs and organisation
I'm in favor of an RFC app on the condition it has a nice UX and has complete unit tests. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFCs and organisation
On 26/07/12 18:46, Levi Morrison wrote: I'm in favor of an RFC app on the condition it has a nice UX and has complete unit tests. Welp, guess it's time for me to learn how to unit-test properly. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFCs and organisation
On Thu, Jul 26, 2012 at 10:47 AM, Andrew Faulds a...@ajf.me wrote: On 26/07/12 18:46, Levi Morrison wrote: I'm in favor of an RFC app on the condition it has a nice UX and has complete unit tests. Welp, guess it's time for me to learn how to unit-test properly. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Probably best not to just throw something together halphazardly. It's not like we're up against a ticking clock or anything. What do we currently use for data storage? MySQL, etc? I think it would be best to take a multi-vector approach to this. I.e. somebody handles the backend core, another person handles the UI templates, somebody familiar with the existing VCS architecture takes care of auth integration, and someone else looks into the formatting options. I could handle the backend core and put together a nice AJAX/MVC architecture that'll make it easier for other dev roles to be properly segregated. I could have that done by the time Andrew gets back easily enough. Oh and it should of course also be maintained on Git. =) --Kris
Re: [PHP-DEV] RFCs and organisation
On 26/07/12 18:53, Kris Craig wrote: On Thu, Jul 26, 2012 at 10:47 AM, Andrew Faulds a...@ajf.me mailto:a...@ajf.me wrote: On 26/07/12 18:46, Levi Morrison wrote: I'm in favor of an RFC app on the condition it has a nice UX and has complete unit tests. Welp, guess it's time for me to learn how to unit-test properly. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Probably best not to just throw something together halphazardly. It's not like we're up against a ticking clock or anything. What do we currently use for data storage? MySQL, etc? I think it would be best to take a multi-vector approach to this. I.e. somebody handles the backend core, another person handles the UI templates, somebody familiar with the existing VCS architecture takes care of auth integration, and someone else looks into the formatting options. I could handle the backend core and put together a nice AJAX/MVC architecture that'll make it easier for other dev roles to be properly segregated. I could have that done by the time Andrew gets back easily enough. Oh and it should of course also be maintained on Git. =) --Kris Sounds like a plan. Personally I like SQLite because of its simple data types, it's flat-file, and it's reasonable for frequent read, infrequent write sites like this. And I'm on GitHub. I'll get hacking :) -- Andrew Faulds http://ajf.me/
Re: [PHP-DEV] RFCs and organisation
On Jul 26, 2012, at 7:53 PM, Kris Craig wrote: On Thu, Jul 26, 2012 at 10:47 AM, Andrew Faulds a...@ajf.me wrote: On 26/07/12 18:46, Levi Morrison wrote: I'm in favor of an RFC app on the condition it has a nice UX and has complete unit tests. Welp, guess it's time for me to learn how to unit-test properly. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Probably best not to just throw something together halphazardly. It's not like we're up against a ticking clock or anything. What do we currently use for data storage? MySQL, etc? How about using git for the actual documents too.. No better way to collaborate imho. Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFCs and organisation
On 26/07/12 19:11, Evert Pot wrote: On Jul 26, 2012, at 7:53 PM, Kris Craig wrote: On Thu, Jul 26, 2012 at 10:47 AM, Andrew Faulds a...@ajf.me wrote: On 26/07/12 18:46, Levi Morrison wrote: I'm in favor of an RFC app on the condition it has a nice UX and has complete unit tests. Welp, guess it's time for me to learn how to unit-test properly. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Probably best not to just throw something together halphazardly. It's not like we're up against a ticking clock or anything. What do we currently use for data storage? MySQL, etc? How about using git for the actual documents too.. No better way to collaborate imho. Evert Ooh, sounds like a good idea. We could have php-rfc repo, and then an online viewer that shows the latest official snapshot, or something like that. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Release Frequency, NEWS, etc.
On 07/26/2012 08:41 AM, Johannes Schlüter wrote: I would therefore like to reduce the 5.3 pace. This is reasonable. The current idea would be to skip every second release (unless security issues demand something else) both in release date as well as version number. Skipping numbers will cause short long term confusion. The current number synchronicity between 5.3 5.4 isn't particularly obvious or useful. Doing this has an obvious issue, though: NEWS entries are currently only placed in the lowest branch. With the example from above and the current way the NEWS are handled 5.4.6 NEWS would be quite small and there would be no 5.3 NEWS to check for further things. NEWS handling is broken anyway. Now would be a good time to resolve the issues with it. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Release Frequency, NEWS, etc.
hi Johannes, On Thu, Jul 26, 2012 at 5:41 PM, Johannes Schlüter johan...@schlueters.de wrote: Hi, since 5.4.0 was released on March 1st we had 6 releases for 5.3 and 5.4 Basically following the mandate At least one release per month, more at wish from the release process RFC[1] with some additional emergency releases in between. The synchrony between those two means that currently 5.3 is nice 10 releases ahead (5.3.15 and 5.4.5 were released together, 5.3.14 and 5.4.4 were etc.). This is nice as you can easily guess that a fix in 5.3.13 will be in 5.4.3, too. And this is very (very) good for our users. Now such a fast, monthly cycle might be good for 5.4 but for 5.3 I think we should slow it down. In my opinion we should try to promote 5.4 over 5.3, give mit more exclusive visibility. People who stay on 5.3 expect to have a stable foundation, and aren't eager to check whether an update is relevant to them that often, especially as most (all?) things fixed in 5.3 are bugs which exist for a few years already. My expectation therefore is that users spend less attention on these and therefore miss critical fixes. As far as I can tell, almost all releases had security related fixes in them, 5.3 or 5.4. Given that, I do not see why we should slow down anything as it will create more issues than what you would like to solve. I would therefore like to reduce the 5.3 pace. I won't. The current idea would be to skip every second release (unless security issues demand something else) both in release date as well as version number. So for instance 5.4.6 will be released sometime next month alone. A month later there will be 5.3.17 and 5.4.7. Right, if there is no bug fix, there is no point to release. But if there are fixes, then let release them at the same time, I see absolutely no point to skip every 2nd release with 5.3 but to spare time (which is not really an argument here :). In short, either we support 5.3 with all kind of bug fixes or only security fixes, or we don't support at all anymore. But some random decision like that is only confusing and makes no sense. There is that RFC that I would like to push to decide the EOL of 5.3, let decide that instead :). Any comments on the general idea or suggestions for the NEWS thing? NEWS is a big issue right now. Last time I discussed that with David, we came to the point where we should: - enforce the commit log format (see the git workflow, https://wiki.php.net/vcs/gitworkflow#new_commit_message_format) - create a script to generate NEWS based on the commit log - if possible, enforce creation of bug # too for each fix/feature/change, so it could be easily tracked 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] RFCs and organisation
On 26/07/12 16:44, Laupretre François wrote: There was a time when one could have written an app for it in PHP ;) Right. We all know from the beginning that a wiki is better than nothing but, when the number of users/documents grows, it becomes very hard to keep the information up-to-date. Another problem is that documents and their comments are not stored together. The RFC remains, which is fine, but the comments fly away, except if the author manually copies them from the list. IMHO, this is the main drawback of the current system: when I read an RFC, I also want to read the comments because they're an integral part of the RFC life. It does not mean that they should not be mirrored to the mailing list, but it is essential to store them with the RFC. Maybe it is time to replace the wiki with a real RFC app. Thoughts ? Do you know of an existing app used by a similar development community ? If not, what would you build it from ? Who would be ready to participate ? Regards François In a reversal of what I said before... not yet. A better organised RFC page would be better. I'd be happy to help sort and organise it. So, how do I get permissions to edit the RFC page? I'm not going to fundamentally change anything. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFCs and organisation
On Thu, Jul 26, 2012 at 12:34 PM, Andrew Faulds a...@ajf.me wrote: On 26/07/12 16:44, Laupretre François wrote: There was a time when one could have written an app for it in PHP ;) Right. We all know from the beginning that a wiki is better than nothing but, when the number of users/documents grows, it becomes very hard to keep the information up-to-date. Another problem is that documents and their comments are not stored together. The RFC remains, which is fine, but the comments fly away, except if the author manually copies them from the list. IMHO, this is the main drawback of the current system: when I read an RFC, I also want to read the comments because they're an integral part of the RFC life. It does not mean that they should not be mirrored to the mailing list, but it is essential to store them with the RFC. Maybe it is time to replace the wiki with a real RFC app. Thoughts ? Do you know of an existing app used by a similar development community ? If not, what would you build it from ? Who would be ready to participate ? Regards François In a reversal of what I said before... not yet. A better organised RFC page would be better. I'd be happy to help sort and organise it. So then, we're not going to write a new RFC app? Or are you just talking about tweaking the wiki while the app is under development? --Kris
Re: [PHP-DEV] RFCs and organisation
On 26/07/12 20:58, Kris Craig wrote: On Thu, Jul 26, 2012 at 12:34 PM, Andrew Faulds a...@ajf.me mailto:a...@ajf.me wrote: On 26/07/12 16:44, Laupretre François wrote: There was a time when one could have written an app for it in PHP ;) Right. We all know from the beginning that a wiki is better than nothing but, when the number of users/documents grows, it becomes very hard to keep the information up-to-date. Another problem is that documents and their comments are not stored together. The RFC remains, which is fine, but the comments fly away, except if the author manually copies them from the list. IMHO, this is the main drawback of the current system: when I read an RFC, I also want to read the comments because they're an integral part of the RFC life. It does not mean that they should not be mirrored to the mailing list, but it is essential to store them with the RFC. Maybe it is time to replace the wiki with a real RFC app. Thoughts ? Do you know of an existing app used by a similar development community ? If not, what would you build it from ? Who would be ready to participate ? Regards François In a reversal of what I said before... not yet. A better organised RFC page would be better. I'd be happy to help sort and organise it. So then, we're not going to write a new RFC app? Or are you just talking about tweaking the wiki while the app is under development? --Kris I think it's best to do what we can with the wiki, as it stands. There are plenty of things we haven't tried. There are macros and such. -- Andrew Faulds http://ajf.me/
Re: [PHP-DEV] strict compliance ...
I did start making fixes, but it drove me up the wall, the pointlessness and stupidity of this change... Eventually I just disabled E_STRICT in the bootstrap code... I think we should allow a free for all on commits to fix this, unless anyone objects... Regards Alan -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Lester Caine les...@lsces.co.uk wrote: I know I'll be kicked somewhere else, but I think it's important that the general community appreciates what is going on ... I've cleared the bulk of the 'strict' warnings on bitweaver, and in the libraries, but now I'm down to PEAR ... is there a version of PEAR that is strict compliant? I've certainly not found anything and now I'm having to work through that to remove the next layer of warnings! So is anybody else working on the same problem? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
2012/7/26 Bernhard Schussek bschus...@gmail.com: [about doc-blocks] Fact: Doc blocks are not forced by the language. Fact: For an IDE an own keyword will help the parser to distinct faster/easier between normal functions and a generator. Experience: IDEs will have their problems implementing this - think at first try this isn't implemented with all consequences, so they may not be helpful to see the difference. -- Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
