Re: [PHP-DEV] 5.4 again
On Mon, May 9, 2011 at 5:31 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 05/08/2011 04:40 PM, Stas Malyshev wrote: I has been almost a month since we did our routine talk about 5.4, so here it goes again. The patch for the scalar hints seems to be pretty simple (see http://random-bits-of.info/no_scalar_hints.diff - no generated files included, that will be done on actual commit), so it should not hold us too much. I propose putting current code in a branch and continue without scalar typing for 5.4 - any objections to that? I would like to propose the following process (of course, dates can be moved around, etc. - I consider phase lengths be more important that actual dates, but any of them can be shifted if reason arises) for 5.4: - starting now - nominate features for 5.4 (see https://wiki.php.net/todo/php54), discussion on them - May 18 - start voting and debating on features that have no clear consensus support immediately. On the end of May is also phptek, so we could have some discussion there about it if needed. - June 15 (a bit more than a month) - alpha, branching of 5_4, open only for bugfixes and features in TODO list that are approved and can be done by beta time. - July 20 - beta, bugfixes only (if we add a lot of features, we may want to insert another 1-month alpha period, so far it doesn't look like it but may change) - Aug 24 - RC1, then an RC every 2 weeks until stable - Release - somewhere in October or November, depending on the RCs. I think we need to start moving. Not much is happening in 5.4 now as far as I can see, and we have a good feature set that is long due to be released. For proposing stuff for 5.4, please do it here: https://wiki.php.net/todo/php54 and also on the list if it wasn't discussed and you think it requires discussion. Looks good to me. I see the array shortcuts are on your todo discussion list there. We probably shouldn't get into a full discussion on that since it will span hundreds of messages. But if any of the folks who voted no last time around have changed their minds, it would be good to know. And before deciding, try using MongoDB from PHP for a couple of weeks. :) maybe it would be a good idea to gather the pros/cons which was brought up in the last discussion/poll. another thing that I would love to see on the list: named parameters. it was recently brought up, and I think that the original argument for the rejection isn't true anymore: http://www.php.net/~derick/meeting-notes.html#named-parameters adding naming parameters would actually help to make clean and maintainable code. currently if you want optional params, you either have to create long list of arguments with default values, and call your functions like -$foo-bar($a, $b, NULL, NULL, false, $c), or you have to put your argument into an array/object and pass that to your function, which pretty much defeats the purpose. I don't propose that we should hold up the release process with that, but we should at least consider it for inclusion. what do you think? Tyrael
Re: [PHP-DEV] 5.4 again
Hi! another thing that I would love to see on the list: named parameters. it was recently brought up, and I think that the original argument for the rejection isn't true anymore: http://www.php.net/~derick/meeting-notes.html#named-parameters adding naming parameters would actually help to make clean and maintainable code. I'm all for this idea, but the question is - can we have a good design implementation in next 2 months? If we can, great, if we can't - I'd rather have 5.4 than wait for it. E.g., if we have somebody ready to commit for certain timeframe to come up with it, then it makes sense to discuss it in this context. -- 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] 5.4 again
Hi: On 09 May 2011, at 09:50, Stas Malyshev wrote: I'm all for this idea, but the question is - can we have a good design implementation in next 2 months? If we can, great, if we can't - I'd rather have 5.4 than wait for it. E.g., if we have somebody ready to commit for certain timeframe to come up with it, then it makes sense to discuss it in this context. Can't we just draw this arbitrary line in the sand, and say from now on, controversial things are taken out and nothing new is added anymore? Everything which is not yet in trunk and is not required to round up the release should go into the release after 5.4? For me it seems there is no progress because there is still to much opportunity to improve things... So, instead of allowing to nominate new features, it might be best to stick to what we have now, and restrict ourselves to sort out the controversial stuff. 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] 5.4 again
On Mon, May 9, 2011 at 9:50 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! another thing that I would love to see on the list: named parameters. it was recently brought up, and I think that the original argument for the rejection isn't true anymore: http://www.php.net/~derick/meeting-notes.html#named-parameters adding naming parameters would actually help to make clean and maintainable code. I'm all for this idea, but the question is - can we have a good design implementation in next 2 months? If we can, great, if we can't - I'd rather have 5.4 than wait for it. E.g., if we have somebody ready to commit for certain timeframe to come up with it, then it makes sense to discuss it in this context. agree. I think we could have a good one (if somebody actually start working on it), so I think we should leave the door open for this and if it's got written and approved before the code freeze then we will include it. Tyrael
Re: [PHP-DEV] 5.4 again
On Mon, May 9, 2011 at 10:00 AM, Stefan Marr p...@stefan-marr.de wrote: Hi: On 09 May 2011, at 09:50, Stas Malyshev wrote: I'm all for this idea, but the question is - can we have a good design implementation in next 2 months? If we can, great, if we can't - I'd rather have 5.4 than wait for it. E.g., if we have somebody ready to commit for certain timeframe to come up with it, then it makes sense to discuss it in this context. Can't we just draw this arbitrary line in the sand, and say from now on, controversial things are taken out and nothing new is added anymore? Everything which is not yet in trunk and is not required to round up the release should go into the release after 5.4? For me it seems there is no progress because there is still to much opportunity to improve things... So, instead of allowing to nominate new features, it might be best to stick to what we have now, and restrict ourselves to sort out the controversial stuff. I think that it would be nice to have a short timeframe before feature freeze. Tyrael
Re: [PHP-DEV] 5.4 again
Hi! I see the array shortcuts are on your todo discussion list there. We probably shouldn't get into a full discussion on that since it will span hundreds of messages. But if any of the folks who voted no last time around have changed their minds, it would be good to know. And before deciding, try using MongoDB from PHP for a couple of weeks. :) I agree on both discussion point and MongoDB point :) I think for things that were already discussed extensively it makes sense to have a vote in case people changed their minds and discuss at length only if they have something new to say - like proposing new approach to the problem - which is this case probably won't happen. -- 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-DEV] Status on Traits
Hi, what is the status of traits, or like the wiki calls it Horizontal Reuse for PHP. AFAIR I got notice of it on the FrOsCon 2008/2009(?), since then lot time passed and the last update on the wiki ist from November last Year. I'm just curious, when will this feature be implemented in a stable release? I would really like to have the possibility of using traits in my code. kalkin- -- Paranoid sein heisst frei sein (Hal Faber) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi, I'd love if you ever discuss these items for 5.4: - ReflectionNamespace Currently it's impossible to grab a docblock that documents an Annotations, for example, or even access the namespace declaration. It's also impossible to check which use is declared on the namespace/file/class scope. - Annotations I already proposed a patch and none here discussed. You rather preferred to shout PHP doesn't need Annotations instead of discuss the patch that was proposed. Actually, it was proposed twice, but it seems that you only looked at first one (which I agree that was incompatible with PHP way of being). Pierrick and I updated the patch to be as similar as possible with PHP structure, but none here even looked at it. For those interested: https://github.com/adoy/PHP-Annotations - SplArray We currently support SplInt, SplString, SplFloat, SplBool, etc. We could support SplArray which would perfectly enhance implementations that need to keep track of array state. Currently PHP provides 0 support on this area, and it would be nice if it provides a helpful API to it. One good example to look at is: https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Collections/Collection.php - Comparable Since operators overloading on PHP is hard to be implemented natively, we could easily support it through OO. This idea can be extensively discussed, but someone already proposed a patch previously any none discussed it. PS: I think that internals mailing list should be revised with all proposed ideas and wrap them on a better plan. It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. Regards, On Mon, May 9, 2011 at 5:38 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I see the array shortcuts are on your todo discussion list there. We probably shouldn't get into a full discussion on that since it will span hundreds of messages. But if any of the folks who voted no last time around have changed their minds, it would be good to know. And before deciding, try using MongoDB from PHP for a couple of weeks. :) I agree on both discussion point and MongoDB point :) I think for things that were already discussed extensively it makes sense to have a vote in case people changed their minds and discuss at length only if they have something new to say - like proposing new approach to the problem - which is this case probably won't happen. -- 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 -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Martin Scotta On Mon, May 9, 2011 at 11:44 AM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi, I'd love if you ever discuss these items for 5.4: - ReflectionNamespace Currently it's impossible to grab a docblock that documents an Annotations, for example, or even access the namespace declaration. It's also impossible to check which use is declared on the namespace/file/class scope. - Annotations I already proposed a patch and none here discussed. You rather preferred to shout PHP doesn't need Annotations instead of discuss the patch that was proposed. Actually, it was proposed twice, but it seems that you only looked at first one (which I agree that was incompatible with PHP way of being). Pierrick and I updated the patch to be as similar as possible with PHP structure, but none here even looked at it. For those interested: https://github.com/adoy/PHP-Annotations - SplArray We currently support SplInt, SplString, SplFloat, SplBool, etc. We could support SplArray which would perfectly enhance implementations that need to keep track of array state. Currently PHP provides 0 support on this area, and it would be nice if it provides a helpful API to it. One good example to look at is: https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Collections/Collection.php - Comparable Since operators overloading on PHP is hard to be implemented natively, we could easily support it through OO. This idea can be extensively discussed, but someone already proposed a patch previously any none discussed it. PS: I think that internals mailing list should be revised with all proposed ideas and wrap them on a better plan. It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. Totally agree. a user. Regards, On Mon, May 9, 2011 at 5:38 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I see the array shortcuts are on your todo discussion list there. We probably shouldn't get into a full discussion on that since it will span hundreds of messages. But if any of the folks who voted no last time around have changed their minds, it would be good to know. And before deciding, try using MongoDB from PHP for a couple of weeks. :) I agree on both discussion point and MongoDB point :) I think for things that were already discussed extensively it makes sense to have a vote in case people changed their minds and discuss at length only if they have something new to say - like proposing new approach to the problem - which is this case probably won't happen. -- 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 -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
On 9 May 2011 15:44, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. But surely it is a motivational factor to learn C, and have a go at implementing the feature yourself! That's what Open Source is all about. If you don't like the feature, or it is missing one, _DO_ something about it. Saying that the developers are not interested isn't really doing anything. You really can't expect volunteers to simply down tools from family, life, paid work to jump through hoops, attempting to make sense of every user's request. No matter how loud they shout. Now. If you had a pot (and a big pot) of money, then maybe you could sponsor some developers for your pet peeve. I'll take your money. As a volunteer to the PHP project (mainly making an arse of myself in as many places as possible) and a PHP user, I am deeply indebted to all the work undertaken by the core devs. I get paid because of them. Please treat the devs nicely is all I'm really saying. Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On May 9, 2011, at 2:38 AM, Stas Malyshev wrote: Hi! I see the array shortcuts are on your todo discussion list there. We probably shouldn't get into a full discussion on that since it will span hundreds of messages. But if any of the folks who voted no last time around have changed their minds, it would be good to know. And before deciding, try using MongoDB from PHP for a couple of weeks. :) I agree on both discussion point and MongoDB point :) I think for things that were already discussed extensively it makes sense to have a vote in case people changed their minds and discuss at length only if they have something new to say - like proposing new approach to the problem - which is this case probably won't happen. I'm changing my old vote, so -1 to +1. Changes and additions to syntax may (or may not) slow adoption, but since other such changes are being made then let's do it. And while explicit code (e.g., array()) is nice, many people are familiar with array shortcuts[1]. And on a related note for those at home, function array dereferencing[2] has already been implemented in trunk. Also, there could probably be a discussion dedicated to arrays as other features/shortcuts like slicing has casually been discussed. [1] https://wiki.php.net/rfc/shortsyntaxforarrays [2] https://wiki.php.net/rfc/functionarraydereferencing Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote: - Annotations I already proposed a patch and none here discussed. You rather preferred to shout PHP doesn't need Annotations instead of discuss the patch that was proposed. If someone doesn't agree that annotations belong in PHP why do the details of the patch matter? PS: I think that internals mailing list should be revised with all proposed ideas and wrap them on a better plan. It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. That's simply not true. But just because one group of users feel strongly about something doesn't mean it should go in. There has to be some level of curation or we end up with every feature under the sun resulting in a huge mess. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi! It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. Of course we are interested in user's requests, and we implemented tons of features at user's requests. That, however, does not mean we will implement _every_ requested feature, and of course for features that we like and understand the chance of being implemented are much higher and for features that core contributors don't feel make sense or go contrary to what they feel PHP should be the chance is low. I don't think it can work any other way, at least not in volunteer-driven project. -- 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] 5.4 again
regarding the annotations stuff: it seems the php community (in general) really wants annotations. lots of important and widely used frameworks use them (meaning that not only the plain php users have a use for this feature, but also the users of the respective frameworks, increasing the overall user number interested). i.e: doctrine, symfony2, ding, phpunit, etc, etc. we cant just ignore this fact. also, this means that there are tons of custom annotations implementations (almost one per framework that has a use for them), and we end up duplicating code and slowing the overall performance for applications. my question is: is php a language made for the php developers that mantain the language or for the community that uses them and contributes to it everyday? just a thought On Mon, May 9, 2011 at 1:44 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote: - Annotations I already proposed a patch and none here discussed. You rather preferred to shout PHP doesn't need Annotations instead of discuss the patch that was proposed. If someone doesn't agree that annotations belong in PHP why do the details of the patch matter? PS: I think that internals mailing list should be revised with all proposed ideas and wrap them on a better plan. It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. That's simply not true. But just because one group of users feel strongly about something doesn't mean it should go in. There has to be some level of curation or we end up with every feature under the sun resulting in a huge mess. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- // I don't sleep. I coffee. Make everything as simple as possible, but not simpler. -- Albert Einstein The class object inherits from Chuck Norris. Chuck Norris can divide by zero and can unit test an entire application with a single assert. There’s a lot of work happening behind the scenes, courtesy of the Spring AOP framework Why do I have this nagging hunch that you have no idea what you're doing? Any society that would give up a little liberty to gain a little security will deserve neither and lose both - Benjamin Franklin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On Mon, May 9, 2011 at 6:55 PM, Marcelo Gornstein marce...@gmail.com wrote: regarding the annotations stuff: it seems the php community (in general) really wants annotations. lots of important and widely used frameworks use them (meaning that not only the plain php users have a use for this feature, but also the users of the respective frameworks, increasing the overall user number interested). i.e: doctrine, symfony2, ding, phpunit, etc, etc. we cant just ignore this fact. also, this means that there are tons of custom annotations implementations (almost one per framework that has a use for them), and we end up duplicating code and slowing the overall performance for applications. my question is: is php a language made for the php developers that mantain the language or for the community that uses them and contributes to it everyday? I don't know if annotations are *needed* in PHP 5.4. There are a few libraries, out there, that can help developers, as you said, from now. Doctrine's one it's really powerful, and you can clone the repo from github and easily start using the annotation library. So my point is to say that, although *we need a unified way to manage annotations* ( for the reasons Marcelo just explained ), they don't need to be a focus point for PHP 5.4. just a thought On Mon, May 9, 2011 at 1:44 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote: - Annotations I already proposed a patch and none here discussed. You rather preferred to shout PHP doesn't need Annotations instead of discuss the patch that was proposed. If someone doesn't agree that annotations belong in PHP why do the details of the patch matter? PS: I think that internals mailing list should be revised with all proposed ideas and wrap them on a better plan. It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. That's simply not true. But just because one group of users feel strongly about something doesn't mean it should go in. There has to be some level of curation or we end up with every feature under the sun resulting in a huge mess. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- // I don't sleep. I coffee. Make everything as simple as possible, but not simpler. -- Albert Einstein The class object inherits from Chuck Norris. Chuck Norris can divide by zero and can unit test an entire application with a single assert. There’s a lot of work happening behind the scenes, courtesy of the Spring AOP framework Why do I have this nagging hunch that you have no idea what you're doing? Any society that would give up a little liberty to gain a little security will deserve neither and lose both - Benjamin Franklin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Nadalin Alessandro www.odino.org www.twitter.com/_odino_ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Hi! my question is: is php a language made for the php developers that mantain the language or for the community that uses them and contributes to it everyday? Please stop trying to manipulate developers by suggesting if they don't do exactly what you want they hate (or don't care for) all users. This is obviously not true and does not contribute to the discussion. As for the merits of the question, the problem is not having annotations in general but having consistent, easy, performant model and implementation that makes sense together with the rest of PHP. So far none that were offered were good enough to satisfy that requirement and gather consensus. I think it's better to wait and revisit it in the future than to rush a half-baked concept now. Which means unless somebody makes really strong proposal right now that people would instantly like - it's not 5.4. It doesn't mean never either - it can always be done in the next version. If there's something new to say on the topic - great, let's see it. -- 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] 5.4 again
Stas Malyshev wrote: It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. Of course we are interested in user's requests, and we implemented tons of features at user's requests. That, however, does not mean we will implement _every_ requested feature, and of course for features that we like and understand the chance of being implemented are much higher and for features that core contributors don't feel make sense or go contrary to what they feel PHP should be the chance is low. I don't think it can work any other way, at least not in volunteer-driven project. I do feel it is about time there was a little back-pedalling and asking 'What do we NEED in PHP'. Personally a lot of the things that are been 'demanded' are of little use to make PHP work any better, and only add to the processing time. If people want a fully typed compiled language why aren't they using python or java ;) My own development framework is phpeclipse, and that give me all of the hinting and error checking that I need IN THE EDITOR, I don't need the language weight down further with bells and whistles that do not improve performance of the end application. PHP used to be a nice nimble interpreted language that I can add pages to without having to compile anything. Nowadays it seems that those days are coming to an end? Keep the hinting and error checking to the tools where they belong. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
mm i don't remember saying anything like that :) i dont want to start an argument here, but maybe you'd like to take things less personal and re-read my post. anyway, i think it's time to stop just saying no, and really collaborate with what the community is suggesting (and already propsed) in order to bring this into php (5.4 or whatever). On Mon, May 9, 2011 at 2:05 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! my question is: is php a language made for the php developers that mantain the language or for the community that uses them and contributes to it everyday? Please stop trying to manipulate developers by suggesting if they don't do exactly what you want they hate (or don't care for) all users. This is obviously not true and does not contribute to the discussion. As for the merits of the question, the problem is not having annotations in general but having consistent, easy, performant model and implementation that makes sense together with the rest of PHP. So far none that were offered were good enough to satisfy that requirement and gather consensus. I think it's better to wait and revisit it in the future than to rush a half-baked concept now. Which means unless somebody makes really strong proposal right now that people would instantly like - it's not 5.4. It doesn't mean never either - it can always be done in the next version. If there's something new to say on the topic - great, let's see it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- -- // I don't sleep. I coffee. Make everything as simple as possible, but not simpler. -- Albert Einstein The class object inherits from Chuck Norris. Chuck Norris can divide by zero and can unit test an entire application with a single assert. There’s a lot of work happening behind the scenes, courtesy of the Spring AOP framework Why do I have this nagging hunch that you have no idea what you're doing? Any society that would give up a little liberty to gain a little security will deserve neither and lose both - Benjamin Franklin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4 again
-Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Sunday, May 08, 2011 4:41 PM To: PHP Internals Subject: [PHP-DEV] 5.4 again Hi! I has been almost a month since we did our routine talk about 5.4, so here it goes again. The patch for the scalar hints seems to be pretty simple (see http://random-bits-of.info/no_scalar_hints.diff - no generated files included, that will be done on actual commit), so it should not hold us too much. I propose putting current code in a branch and continue without scalar typing for 5.4 - any objections to that? -snip- I think we need to start moving. Not much is happening in 5.4 now as far as I can see, and we have a good feature set that is long due to be released. For proposing stuff for 5.4, please do it here: https://wiki.php.net/todo/php54 and also on the list if it wasn't discussed and you think it requires discussion. As I've already pointed out, I am all in favor of starting to run the release process. I do think we should focus on getting out there what we have now (with some tweaks) and not trying to do major new features or we will by definition not be entering a release process. The richer our language (and the more mature and broad our base) the more we have to be concerned with feature creep. - On performance memory consumption - as already mentioned, huge improvements! We may be able to do more but will stay within the release timeline if we make any further improvements. - On square bracket shortcut I was always in favor of (b) in http://marc.info/?l=php-internalsm=11385524494w=2. If this is what we're talking about I personally feel it's an easy one. - Agree type hints goes out. Go!! Andi
Re: [PHP-DEV] 5.4 again
On 2011-05-09, Marcelo Gornstein marce...@gmail.com wrote: regarding the annotations stuff: it seems the php community (in general) really wants annotations. lots of important and widely used frameworks use them (meaning that not only the plain php users have a use for this feature, but also the users of the respective frameworks, increasing the overall user number interested). i.e: doctrine, symfony2, ding, phpunit, etc, etc. we cant just ignore this fact. There are annotations, and annotations. Some folks are perfectly fine with ad-hoc annotations support possible by parsing docblocks (Sebastian B. has mentioned as much in relation to PHPUnit). Others are wanting what is essentially a new, parsable, syntax on top of PHP. Others are interested in this latter, but feel that a userland parser that uses code generation to produce executable PHP code is sufficient. The point is, there's still debate about whether the feature as proposed is needed, and, if so, the full scope of features required to support it, and what implications those have for the language. also, this means that there are tons of custom annotations implementations (almost one per framework that has a use for them), and we end up duplicating code and slowing the overall performance for applications. my question is: is php a language made for the php developers that mantain the language or for the community that uses them and contributes to it everyday? just a thought On Mon, May 9, 2011 at 1:44 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote: - Annotations I already proposed a patch and none here discussed. You rather preferred to shout PHP doesn't need Annotations instead of discuss the patch that was proposed. If someone doesn't agree that annotations belong in PHP why do the details of the patch matter? PS: I think that internals mailing list should be revised with all proposed ideas and wrap them on a better plan. It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. That's simply not true. But just because one group of users feel strongly about something doesn't mean it should go in. There has to be some level of curation or we end up with every feature under the sun resulting in a huge mess. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Mon, 9 May 2011, Marcelo Gornstein wrote: mm i don't remember saying anything like that :) i dont want to start an argument here, but maybe you'd like to take things less personal and re-read my post. anyway, i think it's time to stop just saying no, and really collaborate with what the community is suggesting (and already propsed) in order to bring this into php (5.4 or whatever). Read what Richard just wrote please: That's what Open Source is all about. If you don't like the feature, or it is missing one, _DO_ something about it. Saying that the developers are not interested isn't really doing anything. You really can't expect volunteers to simply down tools from family, life, paid work to jump through hoops, attempting to make sense of every user's request. No matter how loud they shout. cheers, 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] annotations again
-Original Message- From: Marcelo Gornstein [mailto:marce...@gmail.com] Sent: Monday, May 09, 2011 10:20 AM To: Stas Malyshev Cc: guilhermebla...@gmail.com; PHP Internals Subject: Re: [PHP-DEV] annotations again mm i don't remember saying anything like that :) i dont want to start an argument here, but maybe you'd like to take things less personal and re-read my post. anyway, i think it's time to stop just saying no, and really collaborate with what the community is suggesting (and already propsed) in order to bring this into php (5.4 or whatever). I absolutely agree we should be getting input from the various communities whether that's ZF, Symphony, Drupal, etc.. I do feel we get quite a bit of if it's not enough it should keep coming with very clear proposals. It'd also help if the frameworks would collaborate on such proposals. I know our ZF team has collaborated with other framework teams on a variety of fronts. I do think this group does take clear proposals seriously but it's also important to remember that there has to be a strong bias to avoid feature creep and really focus on what's critical and not nice-to-have. There are proposals that come up time and time again like operator overloading which just makes me cringe... Andi
Re: [PHP-DEV] 5.4 again
Hi Rasmus, On Mon, May 9, 2011 at 1:44 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote: - Annotations I already proposed a patch and none here discussed. You rather preferred to shout PHP doesn't need Annotations instead of discuss the patch that was proposed. If someone doesn't agree that annotations belong in PHP why do the details of the patch matter? The actual concern is that someone didn't agree with that and (re-read the thread to comment this), also confirmed that never used Annotations and have a very superficial knowledge of the possibilities, than to me it's more than clear to me that it's not a valid opinion. If it is for you, then PHP has a problem. PS: I think that internals mailing list should be revised with all proposed ideas and wrap them on a better plan. It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. That's simply not true. But just because one group of users feel strongly about something doesn't mean it should go in. There has to be some level of curation or we end up with every feature under the sun resulting in a huge mess. Are you sure? Please take a look at every topic defined on wiki page. Is there ANY topic to be discussed that came from userland? If you say yes, please point me to the thread. What I clearly see there is that every feature defined there came from users with php-src karma. Now I re-ask you, are you really sure it's only a small group that want something or do you now confirm that only php-src users have relevance on features request? -Rasmus -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote: It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. Rasmus Stas have already pointed out this is not valid and lots of user requests are implemented. I'd add that PHP has never had a lot of spare developer capacity. Programmers are not idly sitting around, waiting for random ideas to code up. If you feel strongly about a feature you have to convince the core contributors of its merits and (i) pique the interest of someone capable of implementing it and then help with testing and documentation, or (ii) implement it all yourself. It's easier than ever to get an SVN account, so contributing would be a good way to get karma. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi! - ReflectionNamespace - Annotations - SplArray - Comparable Thanks for the list, it's a good start of the discussion. I have only one note for now - since the goal of all this to try and get 5.4 out before the end of the year, I think that requires some scope limiting. By this I mean that if something is proposed to which the implementation or design isn't obvious, there should be commitment for it to be done in next 2 months. By done I mean both having design with reasonable consensus and full implementation. So if somebody proposes something entirely new that the implementation is not obvious or already existing, he should either make commitment to do this in the next 2 months personally or find somebody who will. Of course, 2 months here doesn't mean exactly 61 days, but it's the timeframe. I.e., if it's an idea let's somebody do it - it might be a perfectly good idea, but not for this 5.4. That doesn't mean it's rejected - it just would be out of scope for this release. -- 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] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
Hi Richard, Again what I commented on other thread and again you barely see what I mentioned, the feature is ALREADY written in C and compatible with latest PHP trunk. I'm not bitching against do and don't dos... I'm bitching about ignored feature that are not even discussed. I agree with you, it's an Open Source project and any help from any front is valuable. But as I pointed out on other thread, only developers with php-src karma had features evaluated. If you think I'm wrong, please re-read the entire thread of Annotations and then get back to me with a single message on thread where actually had a discussion with some mature content instead of personal feelings. Regards, On Mon, May 9, 2011 at 1:13 PM, Richard Quadling rquadl...@gmail.com wrote: On 9 May 2011 15:44, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. But surely it is a motivational factor to learn C, and have a go at implementing the feature yourself! That's what Open Source is all about. If you don't like the feature, or it is missing one, _DO_ something about it. Saying that the developers are not interested isn't really doing anything. You really can't expect volunteers to simply down tools from family, life, paid work to jump through hoops, attempting to make sense of every user's request. No matter how loud they shout. Now. If you had a pot (and a big pot) of money, then maybe you could sponsor some developers for your pet peeve. I'll take your money. As a volunteer to the PHP project (mainly making an arse of myself in as many places as possible) and a PHP user, I am deeply indebted to all the work undertaken by the core devs. I get paid because of them. Please treat the devs nicely is all I'm really saying. Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4 again
-Original Message- From: Christopher Jones [mailto:christopher.jo...@oracle.com] Sent: Monday, May 09, 2011 10:28 AM To: internals@lists.php.net; Guilherme Blanco Subject: Re: [PHP-DEV] 5.4 again On 05/09/2011 07:44 AM, guilhermebla...@gmail.commailto:guilhermebla...@gmail.com wrote: It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. Rasmus Stas have already pointed out this is not valid and lots of user requests are implemented. I'd add that PHP has never had a lot of spare developer capacity. Programmers are not idly sitting around, waiting for random ideas to code up. If you feel strongly about a feature you have to convince the core contributors of its merits and (i) pique the interest of someone capable of implementing it and then help with testing and documentation, or (ii) implement it all yourself. It's easier than ever to get an SVN account, so contributing would be a good way to get karma. I agree but also want to emphasize that just because there’s a patch it doesn’t mean it’s a good idea and should be accepted. Of course like Chris points out it’ll significantly increase the chances of people taking it seriously and playing around with the idea. I also think Matthew makes a good point – annotations can be viewed in different ways and arguably there are already quite a lot of possibilities with what exists today. Andi
Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
On 05/09/2011 10:32 AM, guilhermebla...@gmail.com wrote: Hi Richard, Again what I commented on other thread and again you barely see what I mentioned, the feature is ALREADY written in C and compatible with latest PHP trunk. I'm not bitching against do and don't dos... I'm bitching about ignored feature that are not even discussed. I agree with you, it's an Open Source project and any help from any front is valuable. But as I pointed out on other thread, only developers with php-src karma had features evaluated. If you think I'm wrong, please re-read the entire thread of Annotations and then get back to me with a single message on thread where actually had a discussion with some mature content instead of personal feelings. A lot of people who understand the problem very well weighed in on this feature. Framework authors and others who have a real use for annotations, and there was still no clear agreement. As far as RFCs on the wiki only coming from people with php-src accounts, that is true, since that is our auth system for the wiki. But getting an account, even if it is simply to submit an RFC to the wiki is rather trivial. Or looking at it another way, if the feature is so popular, getting one of the 2000 people with an account to submit the RFC shouldn't be a problem. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
That's simply not true. But just because one group of users feel strongly about something doesn't mean it should go in. There has to be some level of curation or we end up with every feature under the sun resulting in a huge mess. Are you sure? Please take a look at every topic defined on wiki page. Is there ANY topic to be discussed that came from userland? If you say yes, please point me to the thread. What I clearly see there is that every feature defined there came from users with php-src karma. there is at least one, mine but I also think that the core devs and the php userland/community is too far away, we would need more people from the userland to contribute to the development of the php language. http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6 http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6“Because it’s nearly impossible toparticipate on Internals if yourpoo-throwing arm isn’t strong.” — @coates “Those with talent, competence, energy,and good ideas over a period of time - and who outlast the rest - tend to be the main drivers behind PHPdevelopment.” — @a Tyrael
Re: [PHP-DEV] annotations again
Hi all, It's funny how far a simple discussion can reach. I'm not advocating that an specific feature should go in or if not, stimulate hate on developers. Quoting what Richard and Derick posted, it's open source. Any help from any front is very welcome. All I want is a place where users (the entire php userland) can see what was discussed and the results of it. IIRC, open source is about community driven development. I don't see a single thread message that pointed to a mature discussion about feature A or B. All I saw was personal feelings about the inclusion of feature A. I'm a really pro supporter of Annotations in PHP, I also worked on an Annotations patch for you. The first time I got a mature feedback to turn the patch more PHP compatible, I agreed with php dev and worked on changes to it. As soon as I published the patch updated with more ideas and stable code, all I got was Oh, come'on, this thread again!. None ever discussed this and you're (IMHO) saying no without even looking at the patch. I can certain say that you don't even looked at it because Richard (on the other thread) said that I could perfectly have helped you writing C code. If he have ever clicked on link I pointed out, he could clearly see that it's C patch fully tested and compatible with latest php trunk. So, please stop saying no to every feature request that comes in and start to discuss the actual impact of each feature. It's not because the feature came from userland that it doesn't have any structure/design behind. It took months of planning and structuring how it could be. All I need is someone that is not rude and give me some clear feedback about possible enhancements that could be done to be merged into php source code. Thanks. On Mon, May 9, 2011 at 2:22 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Marcelo Gornstein [mailto:marce...@gmail.com] Sent: Monday, May 09, 2011 10:20 AM To: Stas Malyshev Cc: guilhermebla...@gmail.com; PHP Internals Subject: Re: [PHP-DEV] annotations again mm i don't remember saying anything like that :) i dont want to start an argument here, but maybe you'd like to take things less personal and re-read my post. anyway, i think it's time to stop just saying no, and really collaborate with what the community is suggesting (and already propsed) in order to bring this into php (5.4 or whatever). I absolutely agree we should be getting input from the various communities whether that's ZF, Symphony, Drupal, etc.. I do feel we get quite a bit of if it's not enough it should keep coming with very clear proposals. It'd also help if the frameworks would collaborate on such proposals. I know our ZF team has collaborated with other framework teams on a variety of fronts. I do think this group does take clear proposals seriously but it's also important to remember that there has to be a strong bias to avoid feature creep and really focus on what's critical and not nice-to-have. There are proposals that come up time and time again like operator overloading which just makes me cringe... Andi -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
Rasmus, I already wrote an RFC, I already wrote a patch and none from php-src gave me some valuable feedback. During private conversations while flaming messages were popping on ML thread, I updated the code to be more PHP compatible and when I went to update the RFC on wiki, it became offline. BTW, if you think Annotations wouldn't be so popular, please tell the Symfony users (Routing, Validation), Doctrine users (Entire Mapping), Typo3 users, Zend Framework (XML-RPC), PHPUnit users that this feature is useless. If this doesn't count 2000 users using the feature, I think only wordpress users may count this. Cheers, On Mon, May 9, 2011 at 2:38 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 05/09/2011 10:32 AM, guilhermebla...@gmail.com wrote: Hi Richard, Again what I commented on other thread and again you barely see what I mentioned, the feature is ALREADY written in C and compatible with latest PHP trunk. I'm not bitching against do and don't dos... I'm bitching about ignored feature that are not even discussed. I agree with you, it's an Open Source project and any help from any front is valuable. But as I pointed out on other thread, only developers with php-src karma had features evaluated. If you think I'm wrong, please re-read the entire thread of Annotations and then get back to me with a single message on thread where actually had a discussion with some mature content instead of personal feelings. A lot of people who understand the problem very well weighed in on this feature. Framework authors and others who have a real use for annotations, and there was still no clear agreement. As far as RFCs on the wiki only coming from people with php-src accounts, that is true, since that is our auth system for the wiki. But getting an account, even if it is simply to submit an RFC to the wiki is rather trivial. Or looking at it another way, if the feature is so popular, getting one of the 2000 people with an account to submit the RFC shouldn't be a problem. -Rasmus -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi Andi, That's all I want. Someone to at least look at the patch and give me feedback. None here did that, all you're doing is telling no, we don't accept it. Why don't you give me some valuable feedback so I can work on the patch to turn it relevant to you? Regards, On Mon, May 9, 2011 at 2:33 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Christopher Jones [mailto:christopher.jo...@oracle.com] Sent: Monday, May 09, 2011 10:28 AM To: internals@lists.php.net; Guilherme Blanco Subject: Re: [PHP-DEV] 5.4 again On 05/09/2011 07:44 AM, guilhermebla...@gmail.com wrote: It seems to me that you are not interested on user's request and rather accept/implement only what the features that interest you. It's very bad for the language and very bad for all of users. Rasmus Stas have already pointed out this is not valid and lots of user requests are implemented. I'd add that PHP has never had a lot of spare developer capacity. Programmers are not idly sitting around, waiting for random ideas to code up. If you feel strongly about a feature you have to convince the core contributors of its merits and (i) pique the interest of someone capable of implementing it and then help with testing and documentation, or (ii) implement it all yourself. It's easier than ever to get an SVN account, so contributing would be a good way to get karma. I agree but also want to emphasize that just because there’s a patch it doesn’t mean it’s a good idea and should be accepted. Of course like Chris points out it’ll significantly increase the chances of people taking it seriously and playing around with the idea. I also think Matthew makes a good point – annotations can be viewed in different ways and arguably there are already quite a lot of possibilities with what exists today. Andi -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
On 05/09/2011 10:48 AM, guilhermebla...@gmail.com wrote: Rasmus, I already wrote an RFC, I already wrote a patch and none from php-src gave me some valuable feedback. During private conversations while flaming messages were popping on ML thread, I updated the code to be more PHP compatible and when I went to update the RFC on wiki, it became offline. BTW, if you think Annotations wouldn't be so popular, please tell the Symfony users (Routing, Validation), Doctrine users (Entire Mapping), Typo3 users, Zend Framework (XML-RPC), PHPUnit users that this feature is useless. If this doesn't count 2000 users using the feature, I think only wordpress users may count this. Nobody has argued that there isn't a use for annotations. There obviously is. The argument is whether it needs to be in the core of the language when it isn't inherently a runtime thing. A single standard for annotations and non-runtime tools for manipulating that standard is a viable approach as well. That is what people are doing now, except they all picked different ways of doing it. By putting it into the core you are solving that problem since everyone will likely switch to it, but the argument is that that is not a good enough justification for putting it into the core of the language. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
Hi Rasmus, Thanks a lot for the response. This was the first email that I got that is not rude against my patch. I have worked on Doctrine annotations support (which is being used by Symfony and also Typo3), which is a LL(*) parser that processes docblocks and uses runtime classes to build associated information. This relies on 2 points to correctly work: a reader and a cache. These ones are required for 2 reasons: - PHP doesn't currently support annotations (so ReflecionClass/ReflectionProperty/ReflectionMethod cannot have a simplified API to getAnnotations()). The Reader is a composition over ReflectionAPI. - Parsing is expensive and I cannot plugin opcache. To fix the overhead of processing every request, I plugged a cache support. What I thought it could be changed is: - Allow PHP to support it natively and also take advantage of opcode cache - Make API cleaner That's where the idea came. I voted for having it native to ZE because a code with and without comments should behave the same. So this made me to work on something that could be merged into php-src. If possible, could you look at the patch and give me high level ideas of what could be changed? Thanks On Mon, May 9, 2011 at 2:53 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 05/09/2011 10:48 AM, guilhermebla...@gmail.com wrote: Rasmus, I already wrote an RFC, I already wrote a patch and none from php-src gave me some valuable feedback. During private conversations while flaming messages were popping on ML thread, I updated the code to be more PHP compatible and when I went to update the RFC on wiki, it became offline. BTW, if you think Annotations wouldn't be so popular, please tell the Symfony users (Routing, Validation), Doctrine users (Entire Mapping), Typo3 users, Zend Framework (XML-RPC), PHPUnit users that this feature is useless. If this doesn't count 2000 users using the feature, I think only wordpress users may count this. Nobody has argued that there isn't a use for annotations. There obviously is. The argument is whether it needs to be in the core of the language when it isn't inherently a runtime thing. A single standard for annotations and non-runtime tools for manipulating that standard is a viable approach as well. That is what people are doing now, except they all picked different ways of doing it. By putting it into the core you are solving that problem since everyone will likely switch to it, but the argument is that that is not a good enough justification for putting it into the core of the language. -Rasmus -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
Hi! I'm not bitching against do and don't dos... I'm bitching about ignored feature that are not even discussed. I think annotations were discussed very extensively. But I totally can see how one particular aspect could slip through. In this case it is right to remind people about it and restart the discussion - by stating what exactly was missed and what new was out there that in your opinion didn't get enough attention. -- 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] native php annotations
On Mon, Mar 14, 2011 at 7:02 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi all, I promise myself to not revamp this discussion again, but it wasn't me this time! @Etienne: That RFC is outdated. Since the last feedback form internals list, a lot of changes have been made to that RFC. Maybe I should update it ASAP so you can clearly understand what have changed to be compatible with current PHP syntax. If you are interested, Pierrick moved all the recent developments to a github repository, which can be reached here: https://github.com/adoy/PHP-Annotations Take a look at some tests: https://github.com/adoy/PHP-Annotations/blob/master/tests/annotations/parser_021.phpt https://github.com/adoy/PHP-Annotations/blob/master/tests/annotations/ReflectionParameter_getAnnotations_003.phpt https://github.com/adoy/PHP-Annotations/blob/master/tests/annotations/ReflectionClass_getAnnotations_004.phpt Also, there's even an alternative patch that support positioned parameters instead of named ones. We just have to reach an agreement with what PHP core want. @Marcelo: While your proposal looks very good, it lacks of the support to nested Annotation. Consider how userland/framework would use your idea. For example, Symfony2 supports validation of data inside classes inspired on JSR-303 (Bean Validation). Symfony2 takes an advantage of a library Doctrine group (which I'm a core member) created by parsing docblocks. When we created this parser, I created this RFC with the good intention that PHP could benefit of this known feature to enhance current userland developments. The first thing you need is your application still running ok with and without comments. This already breaks all suggestions of creating a PECL extension of docblock parser. I'd like to see what people think about it and make something IN on next PHP major version. now that the wiki is back and this was brought up in the 5.4 release planning, I think it would be a good idea to: - update the RFC to be in sync with the implementation - review the rfc and the patch itself - make the necessary modifications if necessary - decide whether we want this in 5.4 or not. Tyrael
Re: [PHP-DEV] annotations again
Hi! If possible, could you look at the patch and give me high level ideas of what could be changed? If the patch is the same RFC that is at https://wiki.php.net/rfc/annotations, the same problems that were voiced a number of times on the list stay: - it is overly complex (see class User example - it's really a piece of code, I think it should be in the code) - it introduces method call syntax not compatible with the rest of PHP - it introduces object instantiation syntax not compatible with the rest of PHP These issues were mentioned before - were they fixed? The RFC also does not clarify where the code contained in annotations is run and how it would play with bytecode caches. -- 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] native php annotations
Hi Ferenc, I'll update the RFC to match the current implementation. Pierrick is working to extract a diff more simplified so you can quickly look at it. Thanks. On Mon, May 9, 2011 at 3:32 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Mon, Mar 14, 2011 at 7:02 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi all, I promise myself to not revamp this discussion again, but it wasn't me this time! @Etienne: That RFC is outdated. Since the last feedback form internals list, a lot of changes have been made to that RFC. Maybe I should update it ASAP so you can clearly understand what have changed to be compatible with current PHP syntax. If you are interested, Pierrick moved all the recent developments to a github repository, which can be reached here: https://github.com/adoy/PHP-Annotations Take a look at some tests: https://github.com/adoy/PHP-Annotations/blob/master/tests/annotations/parser_021.phpt https://github.com/adoy/PHP-Annotations/blob/master/tests/annotations/ReflectionParameter_getAnnotations_003.phpt https://github.com/adoy/PHP-Annotations/blob/master/tests/annotations/ReflectionClass_getAnnotations_004.phpt Also, there's even an alternative patch that support positioned parameters instead of named ones. We just have to reach an agreement with what PHP core want. @Marcelo: While your proposal looks very good, it lacks of the support to nested Annotation. Consider how userland/framework would use your idea. For example, Symfony2 supports validation of data inside classes inspired on JSR-303 (Bean Validation). Symfony2 takes an advantage of a library Doctrine group (which I'm a core member) created by parsing docblocks. When we created this parser, I created this RFC with the good intention that PHP could benefit of this known feature to enhance current userland developments. The first thing you need is your application still running ok with and without comments. This already breaks all suggestions of creating a PECL extension of docblock parser. I'd like to see what people think about it and make something IN on next PHP major version. now that the wiki is back and this was brought up in the 5.4 release planning, I think it would be a good idea to: - update the RFC to be in sync with the implementation - review the rfc and the patch itself - make the necessary modifications if necessary - decide whether we want this in 5.4 or not. Tyrael -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Mon, May 9, 2011 at 8:35 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! If possible, could you look at the patch and give me high level ideas of what could be changed? If the patch is the same RFC that is at https://wiki.php.net/rfc/annotations, the same problems that were voiced a number of times on the list stay: - it is overly complex (see class User example - it's really a piece of code, I think it should be in the code) - it introduces method call syntax not compatible with the rest of PHP - it introduces object instantiation syntax not compatible with the rest of PHP These issues were mentioned before - were they fixed? The RFC also does not clarify where the code contained in annotations is run and how it would play with bytecode caches. please read the other thread, I brought up the original thread (the more php friendly version), as it was mentioned, the rfc didn't up to date AFAIK. Tyrael
Re: [PHP-DEV] annotations again
Hi Stas,
Comments inline.
On Mon, May 9, 2011 at 3:35 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
If possible, could you look at the patch and give me high level ideas
of what could be changed?
If the patch is the same RFC that is at
https://wiki.php.net/rfc/annotations, the same problems that were voiced a
number of times on the list stay:
Currently it's not.
When I was going to update it, wiki went offline.
- it is overly complex (see class User example - it's really a piece of
code, I think it should be in the code)
That's just an example. I'll simplify it.
The main point there was to illustrate the ability to support nested
annotations. Exmaple using @:
@A(@B)
- it introduces method call syntax not compatible with the rest of PHP
- it introduces object instantiation syntax not compatible with the rest of
PHP
This is already fixed.
@A(@B) would require class A like this:
class A {
public function __construct(B $b) { ... }
}
class B {}
These issues were mentioned before - were they fixed?
So your short answer is yes. =)
The RFC also does not clarify where the code contained in annotations is run
and how it would play with bytecode caches.
Sorry, this was one of the things that I was going to update. I'll
include it too.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi: On 09 May 2011, at 19:25, guilhermebla...@gmail.com wrote: Are you sure? Please take a look at every topic defined on wiki page. Is there ANY topic to be discussed that came from userland? If you say yes, please point me to the thread. What I clearly see there is that every feature defined there came from users with php-src karma. Now I re-ask you, are you really sure it's only a small group that want something or do you now confirm that only php-src users have relevance on features request? Just for the sake of argument, a single counter-example can prove you wrong. And that counter-example is traits. I implemented the traits long before I got actual karma, and why do we have traits in trunk now? Because I kept arguing that they are useful, and that I as a user want them. Others liked the idea, and eventually I got the karma to push the code into the official repository. First it was developed completely outside of PHP and without asking anyone from internals, just because I wanted it... That is how open source works. 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] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
guilhermebla...@gmail.com wrote: What I thought it could be changed is: - Allow PHP to support it natively and also take advantage of opcode cache - Make API cleaner Guilherme you still also have to explain WHY we need this. I have a perfectly functional documentation and hinting setup working from docblock entries in several years worth of code. Rewriting all of that would have to have some reason, and working with two systems in parallel does not make sense. My current method of working is well supported in phpeclipse while your new offering will require some major work in phpeclipse and other tools simply to access it? More work for other open source developers who again probably don't need it. So as far as I am concerned I need to be persuaded why this code needs to be IN the core code when I for one can't see any reason to use it. Just because COMPILED languages have it is not a reason to load an interpreted language with it. Adding it as a removable extension might make more sense to me, just as much of the less used code can be disabled if we want. And I was coding in C/C++ long before I switched TO PHP to get away from the problems of using compiled languages for dynamic web based systems. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On Mon, May 9, 2011 at 12:44 PM, Ferenc Kovacs i...@tyrael.hu wrote: That's simply not true. But just because one group of users feel strongly about something doesn't mean it should go in. There has to be some level of curation or we end up with every feature under the sun resulting in a huge mess. Are you sure? Please take a look at every topic defined on wiki page. Is there ANY topic to be discussed that came from userland? If you say yes, please point me to the thread. What I clearly see there is that every feature defined there came from users with php-src karma. there is at least one, mine but I also think that the core devs and the php userland/community is too far away, we would need more people from the userland to contribute to the development of the php language. http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6 http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6 “Because it’s nearly impossible toparticipate on Internals if yourpoo-throwing arm isn’t strong.” — @coates “Those with talent, competence, energy,and good ideas over a period of time - and who outlast the rest - tend to be the main drivers behind PHPdevelopment.” — @a Tyrael Hi, After having some experience participating in other open-source communities, specially Joomla (but also Mootools, Doctrine and Symfony), my first impression when subscribing and reading this list was: wow, its hostile, and I automatically refrained from wanting to participate and chose just to observe for the meantime. I know every community is different, but, even if a single person states something that might look like a problem it is an indicator that you might have it. I think the PHP community could benefit from a process like Python's PEP Workflow: http://www.python.org/dev/peps/pep-0001/#pep-work-flow. Personal attacks achieve nothing, and contributing to open-source is MORE than contributing code, and even if you do contribute, it doesn't look like it is even an automatic way to get the needed attention. I've seen Guilherme post several times asking for feedback (i.e. building upon his work, not just criticizing him) and I have never seen it. I don't think Guilherme loves spending his afternoons advancing in a patch without the slightest sense of community direction. Being brutally honest, looks to me that this generalized attitude/culture might actually be scaring willing devs away, and the community itself needs some kind of direction. Here is a recommended watch: O'Reilly MySQL CE 2010: Jono Bacon, The Engines Of Community: http://blip.tv/file/3495291 Best regards, David
Re: [PHP-DEV] 5.4 again
Seems like a good plan to me. Hopefully as per schedule it gets us 5.4 this year. On Sun, May 8, 2011 at 7:40 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I has been almost a month since we did our routine talk about 5.4, so here it goes again. The patch for the scalar hints seems to be pretty simple (see http://random-bits-of.info/no_scalar_hints.diff - no generated files included, that will be done on actual commit), so it should not hold us too much. I propose putting current code in a branch and continue without scalar typing for 5.4 - any objections to that? I would like to propose the following process (of course, dates can be moved around, etc. - I consider phase lengths be more important that actual dates, but any of them can be shifted if reason arises) for 5.4: - starting now - nominate features for 5.4 (see https://wiki.php.net/todo/php54), discussion on them - May 18 - start voting and debating on features that have no clear consensus support immediately. On the end of May is also phptek, so we could have some discussion there about it if needed. - June 15 (a bit more than a month) - alpha, branching of 5_4, open only for bugfixes and features in TODO list that are approved and can be done by beta time. - July 20 - beta, bugfixes only (if we add a lot of features, we may want to insert another 1-month alpha period, so far it doesn't look like it but may change) - Aug 24 - RC1, then an RC every 2 weeks until stable - Release - somewhere in October or November, depending on the RCs. I think we need to start moving. Not much is happening in 5.4 now as far as I can see, and we have a good feature set that is long due to be released. For proposing stuff for 5.4, please do it here: https://wiki.php.net/todo/php54 and also on the list if it wasn't discussed and you think it requires discussion. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4 again
-Original Message- From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] Sent: Monday, May 09, 2011 10:51 AM To: Andi Gutmans Cc: Christopher Jones; internals@lists.php.net Subject: Re: [PHP-DEV] 5.4 again Hi Andi, That's all I want. Someone to at least look at the patch and give me feedback. None here did that, all you're doing is telling no, we don't accept it. Why don't you give me some valuable feedback so I can work on the patch to turn it relevant to you? I think more important than the patch is the actual functionality. Patch can always be fixed. I assume the latest RFC is https://wiki.php.net/rfc/annotations? I will take a bit of a longer look at it in the coming days but from looking at it quickly I can see why some people may not be very excited about it. I personally have never been a huge fan of meta-data whether in the code or outside the code. The biggest scars I carry are from J2EE. I feel annotations are sometimes just a nicer way of creating similar problems (hard to understand flow, hard to debug, etc…). I do realize there are also some benefits but as Matthew pointed out the question is are those benefits enough to warrant a whole new grammar in the language or do we keep it lighter weight and let people build on that (which with the right caching should not be too hard). Anyway, I will take a longer look. Andi (hoping I don’t get extra newlines this time around. My apologies but for some reason my mail client doesn’t like internals@ in the past two weeks).
Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
Hi Lester, I updated the RFC. I may have missed one thing or two, but overall idea and how code behave is there. This question is answered on wiki RFC. =) Here is the direct link: https://wiki.php.net/rfc/annotations Regards, On Mon, May 9, 2011 at 6:42 PM, Lester Caine les...@lsces.co.uk wrote: guilhermebla...@gmail.com wrote: What I thought it could be changed is: - Allow PHP to support it natively and also take advantage of opcode cache - Make API cleaner Guilherme you still also have to explain WHY we need this. I have a perfectly functional documentation and hinting setup working from docblock entries in several years worth of code. Rewriting all of that would have to have some reason, and working with two systems in parallel does not make sense. My current method of working is well supported in phpeclipse while your new offering will require some major work in phpeclipse and other tools simply to access it? More work for other open source developers who again probably don't need it. So as far as I am concerned I need to be persuaded why this code needs to be IN the core code when I for one can't see any reason to use it. Just because COMPILED languages have it is not a reason to load an interpreted language with it. Adding it as a removable extension might make more sense to me, just as much of the less used code can be disabled if we want. And I was coding in C/C++ long before I switched TO PHP to get away from the problems of using compiled languages for dynamic web based systems. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi Andi, Sorry, but I mentioned on other thread that RFC is outdated. I just finished an update to it bringing to recent implementation. The idea is to get the big picture here, I may have left from previous RFC, but if I did that, please just point out and I can fix. This implementation is *way* simpler. Here is the direct link: https://wiki.php.net/rfc/annotations Regards, On Mon, May 9, 2011 at 7:39 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] Sent: Monday, May 09, 2011 10:51 AM To: Andi Gutmans Cc: Christopher Jones; internals@lists.php.net Subject: Re: [PHP-DEV] 5.4 again Hi Andi, That's all I want. Someone to at least look at the patch and give me feedback. None here did that, all you're doing is telling no, we don't accept it. Why don't you give me some valuable feedback so I can work on the patch to turn it relevant to you? I think more important than the patch is the actual functionality. Patch can always be fixed. I assume the latest RFC is https://wiki.php.net/rfc/annotations? I will take a bit of a longer look at it in the coming days but from looking at it quickly I can see why some people may not be very excited about it. I personally have never been a huge fan of meta-data whether in the code or outside the code. The biggest scars I carry are from J2EE. I feel annotations are sometimes just a nicer way of creating similar problems (hard to understand flow, hard to debug, etc…). I do realize there are also some benefits but as Matthew pointed out the question is are those benefits enough to warrant a whole new grammar in the language or do we keep it lighter weight and let people build on that (which with the right caching should not be too hard). Anyway, I will take a longer look. Andi (hoping I don’t get extra newlines this time around. My apologies but for some reason my mail client doesn’t like internals@ in the past two weeks). -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
guilhermebla...@gmail.com wrote: Hi Lester, I updated the RFC. I may have missed one thing or two, but overall idea and how code behave is there. This question is answered on wiki RFC. =) Here is the direct link: https://wiki.php.net/rfc/annotations But there is nothing there that explains why this is any use where we are not compiling code ... and are all things we are already doing with comment blocks ... which CAN be stripped to speed up operation once in a production environment. A compiler simply strips the unnecessary stuff when building the running code, how do you propose PHP does that ? If I want compiled code then I can use any number of other languages, PHP simply runs what I have in the file. Regards, On Mon, May 9, 2011 at 6:42 PM, Lester Caineles...@lsces.co.uk wrote: guilhermebla...@gmail.com wrote: What I thought it could be changed is: - Allow PHP to support it natively and also take advantage of opcode cache - Make API cleaner Guilherme you still also have to explain WHY we need this. I have a perfectly functional documentation and hinting setup working from docblock entries in several years worth of code. Rewriting all of that would have to have some reason, and working with two systems in parallel does not make sense. My current method of working is well supported in phpeclipse while your new offering will require some major work in phpeclipse and other tools simply to access it? More work for other open source developers who again probably don't need it. So as far as I am concerned I need to be persuaded why this code needs to be IN the core code when I for one can't see any reason to use it. Just because COMPILED languages have it is not a reason to load an interpreted language with it. Adding it as a removable extension might make more sense to me, just as much of the less used code can be disabled if we want. And I was coding in C/C++ long before I switched TO PHP to get away from the problems of using compiled languages for dynamic web based systems. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
Hi! I updated the RFC. I may have missed one thing or two, but overall idea and how code behave is there. This question is answered on wiki RFC. =) Here is the direct link: https://wiki.php.net/rfc/annotations Some questions I didn't find the answers in the RFC: 1. When the annotation objects are instantiated? 2. What is permissible in the arguments of annotation - e.g. can I put any expression there? 3. What Foo(Bar) actually means and how it is supposed to be parsed? 4. What happens if ctor for annotation has error/exception? 5. Are there any limitations on classes that can be used as annotations? 6. Do we need any special support for bytecode caches? -- 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] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
Hi Lester, What you don't see is that you're against having it because you already had the effort to built this support. So answering your question related to use cases, you own codebase is a good example. You had to create a parser for docblock because PHP doesn't have support. And now you're asking me why is it needed because you already implemented it. It's like chicken and eggs. You wouldn't need to implement a docblock parser IF PHP already supported it. Also, you own comments answer you own question. You compile your code for production removing the docblocks (or adding a cache, or generating a file, etc, whatever you want). What does it prohibit you from doing the same with native support? Regards, On Mon, May 9, 2011 at 9:25 PM, Lester Caine les...@lsces.co.uk wrote: guilhermebla...@gmail.com wrote: Hi Lester, I updated the RFC. I may have missed one thing or two, but overall idea and how code behave is there. This question is answered on wiki RFC. =) Here is the direct link: https://wiki.php.net/rfc/annotations But there is nothing there that explains why this is any use where we are not compiling code ... and are all things we are already doing with comment blocks ... which CAN be stripped to speed up operation once in a production environment. A compiler simply strips the unnecessary stuff when building the running code, how do you propose PHP does that ? If I want compiled code then I can use any number of other languages, PHP simply runs what I have in the file. Regards, On Mon, May 9, 2011 at 6:42 PM, Lester Caineles...@lsces.co.uk wrote: guilhermebla...@gmail.com wrote: What I thought it could be changed is: - Allow PHP to support it natively and also take advantage of opcode cache - Make API cleaner Guilherme you still also have to explain WHY we need this. I have a perfectly functional documentation and hinting setup working from docblock entries in several years worth of code. Rewriting all of that would have to have some reason, and working with two systems in parallel does not make sense. My current method of working is well supported in phpeclipse while your new offering will require some major work in phpeclipse and other tools simply to access it? More work for other open source developers who again probably don't need it. So as far as I am concerned I need to be persuaded why this code needs to be IN the core code when I for one can't see any reason to use it. Just because COMPILED languages have it is not a reason to load an interpreted language with it. Adding it as a removable extension might make more sense to me, just as much of the less used code can be disabled if we want. And I was coding in C/C++ long before I switched TO PHP to get away from the problems of using compiled languages for dynamic web based systems. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
Hi Stas,
On Mon, May 9, 2011 at 9:35 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I updated the RFC. I may have missed one thing or two, but overall
idea and how code behave is there.
This question is answered on wiki RFC. =)
Here is the direct link: https://wiki.php.net/rfc/annotations
Some questions I didn't find the answers in the RFC:
1. When the annotation objects are instantiated?
Objects are only instantiated when requested (getAnnotations() or
getAnnotation())
2. What is permissible in the arguments of annotation - e.g. can I put any
expression there?
You are allowed to use any scalar value + array + any object that
implements ReflectionAnnotation interface.
3. What Foo(Bar) actually means and how it is supposed to be parsed?
It would instantiate a class Bar and would pass it as an instance of
Foo that is also being created when doing getAnnotations() or
getAnnotation('Foo')
4. What happens if ctor for annotation has error/exception?
There're error support just like PHP has. Here is a sample:
Fatal error: Uncaught exception 'Exception' with message 'Fo' in
/src/php-src/trunk/ok.php:6
Stack trace:
#0 [internal function]: simpleannotation-__construct()
#1 /src/php-src/trunk/ok.php(15):
ReflectionClass-getAnnotation('simpleannotatio...')
#2 {main}
thrown in /src/php-src/trunk/ok.php on line 6
Code:
class SimpleAnnotation implements ReflectionAnnotation {
public function __construct()
{
throw new Exception('Fo');
}
}
SimpleAnnotation
class Foo {
}
$r = new ReflectionClass('Foo');
var_dump($r-getAnnotation('SimpleAnnotation'));
5. Are there any limitations on classes that can be used as annotations?
As I said, only classes that implement ReflectionAnnotation are
allowed to be used. It gives errors if you attempt to do something
invalid.
Here is the error you get if you attempt to use a non-declared annotation:
class Foo implements ReflectionAnnotation {
public function __construct($bar)
{}
}
class Bar {}
Foo(Bar)
class FooBar {
}
$r = new ReflectionClass('FooBar');
var_dump($r-getAnnotations());
Fatal error: ReflectionClass::getAnnotations(): 'Bar' must implement
'ReflectionAnnotation' to act as an annotation in - on line 15
6. Do we need any special support for bytecode caches?
Yes. Every structure which can be annotated now will have a new member
in their C structure which is annotations, this structure is populated
at compile time and store all the metadata information. So if you have
an opcode cache the compilation will not occur, so the annotations
will be NULL. That's why the opcode cache will have to store the
annotations, so that it can be retrieved every time.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
Hi!
Objects are only instantiated when requested (getAnnotations() or
getAnnotation())
So how this happens - does the class store the text of the annotation?
Or expressions in the call are evaluated and stored, but the object is
not instantiated?
What if I call getAnnotation() repeatedly - are they re-instantiated or
stored somewhere, and if so - where?
2. What is permissible in the arguments of annotation - e.g. can I put any
expression there?
You are allowed to use any scalar value + array + any object that
implements ReflectionAnnotation interface.
By scalar value you mean constant value? Are constants allowed?
3. WhatFoo(Bar) actually means and how it is supposed to be parsed?
It would instantiate a class Bar and would pass it as an instance of
Foo that is also being created when doing getAnnotations() or
getAnnotation('Foo')
So when exactly Bar is instantiated - when getAnnotations() is called?
6. Do we need any special support for bytecode caches?
Yes. Every structure which can be annotated now will have a new member
in their C structure which is annotations, this structure is populated
at compile time and store all the metadata information. So if you have
an opcode cache the compilation will not occur, so the annotations
will be NULL. That's why the opcode cache will have to store the
annotations, so that it can be retrieved every time.
This then should be added to the proposal.
--
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] Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: [PHP-DEV] 5.4 again)
Hi,
First, the actual patch is working but Implementation and behavior may
change following all comments. This is still a work in progress and all
comments/contributions from everybody are welcome :)
That said :
On 9 May 2011 21:23, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Objects are only instantiated when requested (getAnnotations() or
getAnnotation())
So how this happens - does the class store the text of the annotation? Or
expressions in the call are evaluated and stored, but the object is not
instantiated?
What if I call getAnnotation() repeatedly - are they re-instantiated or
stored somewhere, and if so - where?
Annotations are stored in a HashTable of zend_annotation.
struct _zend_annotation {
char *annotation_name;
unsigned int aname_len;
HashTable *values;
zval *instance; /* This is not permanent */
};
Once you call the getAnnotation method the reflection class will evaluate
all expressions and instantiate the object. A reference of the object is
then saved in the instance member of the structure. However, we have a plan
to move this instance somewhere else like in a EG.
2. What is permissible in the arguments of annotation - e.g. can I put any
expression there?
You are allowed to use any scalar value + array + any object that
implements ReflectionAnnotation interface.
By scalar value you mean constant value? Are constants allowed?
Yes constants are allowed. Otherwise you can use annotation and static
scalar (same thing as default value of class properties for example)
3. WhatFoo(Bar) actually means and how it is supposed to be parsed?
It would instantiate a class Bar and would pass it as an instance of
Foo that is also being created when doing getAnnotations() or
getAnnotation('Foo')
So when exactly Bar is instantiated - when getAnnotations() is called?
When you call getAnnotation() the reflection method will instantiate Bar,
and then instantiate the Foo object using the Bar instance as first
parameter of the constructor.
6. Do we need any special support for bytecode caches?
Yes. Every structure which can be annotated now will have a new member
in their C structure which is annotations, this structure is populated
at compile time and store all the metadata information. So if you have
an opcode cache the compilation will not occur, so the annotations
will be NULL. That's why the opcode cache will have to store the
annotations, so that it can be retrieved every time.
This then should be added to the proposal.
We will add it
Thanks for your feedback.
Pierrick
--
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] annotations again
Guilherme, As per many of the conversations on annotations one of that hardest parts of it is that there are generally 3 conversations going on about it when this starts to be discussed. It seems many threads are hi-jacked and I can understand why. I would like to state that annotations in the core may be a good idea; however, we have PECL and PECL seems like the perfect place for this. Quite a few extensions have started off in PECL and made their way to the core and several have been moved from the core to PECL. To me annotations support seems like it would be perfect in PECL. Dedicated machines and virtual machines for end users are higher than ever and they seem to continue to grow. This should easily allow folks to put in the PECL module as needed. I would argue that the introduction of this into the core is adding more feature bloat into the language that is not quite needed at this point. There are obviously several improvements that this would allow to be improved and consistent: WSDL / JSON-RPC / XML-RPC / Doctrine / etc. However, I feel extensions like Mongo / Memcached / Gearman have more to add to the PHP core than adding annotations and they live in PECL. Just speaking from the practical point of view. It is great that certain projects that have utilized annotations and created a layer in user land to make annotations a nice thing to utilize. But to continue to argue this point; it just does not seem logical other than the fact that a few projects want to promote annotations should cause it to drop into the core. I for one would like to see this go to PECL and see the up-take then identify if it is needed for the next PHP release after 5.4. It seems a bit early and like it would be crammed into the PHP core without enough discussion. There are obviously many thoughts on this and it will take time to sort out and implementation details then would be further down the trail after some consensus is happening within this feature. Regards, Mike
Re: [PHP-DEV] annotations again
Hi, Annotations as proposed in the RFC can not (or hardly) be develop as an extension (and so can not go into PECL). The proposed feature require modifications directly into the Zend Engine like for the inclusion of a new syntax which imply modification of the parser. Regards, Pierrick On 9 May 2011 23:42, Mike Willbanks pen...@gmail.com wrote: Guilherme, As per many of the conversations on annotations one of that hardest parts of it is that there are generally 3 conversations going on about it when this starts to be discussed. It seems many threads are hi-jacked and I can understand why. I would like to state that annotations in the core may be a good idea; however, we have PECL and PECL seems like the perfect place for this. Quite a few extensions have started off in PECL and made their way to the core and several have been moved from the core to PECL. To me annotations support seems like it would be perfect in PECL. Dedicated machines and virtual machines for end users are higher than ever and they seem to continue to grow. This should easily allow folks to put in the PECL module as needed. I would argue that the introduction of this into the core is adding more feature bloat into the language that is not quite needed at this point. There are obviously several improvements that this would allow to be improved and consistent: WSDL / JSON-RPC / XML-RPC / Doctrine / etc. However, I feel extensions like Mongo / Memcached / Gearman have more to add to the PHP core than adding annotations and they live in PECL. Just speaking from the practical point of view. It is great that certain projects that have utilized annotations and created a layer in user land to make annotations a nice thing to utilize. But to continue to argue this point; it just does not seem logical other than the fact that a few projects want to promote annotations should cause it to drop into the core. I for one would like to see this go to PECL and see the up-take then identify if it is needed for the next PHP release after 5.4. It seems a bit early and like it would be crammed into the PHP core without enough discussion. There are obviously many thoughts on this and it will take time to sort out and implementation details then would be further down the trail after some consensus is happening within this feature. Regards, Mike
Re: [PHP-DEV] annotations again
On 10 May 2011 09:27, Mike Willbanks pen...@gmail.com wrote: I would argue that the introduction of this into the core is adding more feature bloat into the language that is not quite needed at this point. Annotations cannot be considered bloat because are being used increasingly everywhere that is a clear indication that they are required as part of the PHP core as much as many of the Spl classes. It should be clear by now that the PHP community really do want annotations. At this stage, if someone has done the work to make this happen, the discussion really should be more about polishing that contribution and making sure it provides a robust solution to this feature than trying to postpone or find reasons to put this off. Regards, Drak
Re: [PHP-DEV] annotations again
Drak wrote: I would argue that the introduction of this into the core is adding more feature bloat into the language that is not quite needed at this point. Annotations cannot be considered bloat because are being used increasingly everywhere that is a clear indication that they are required as part of the PHP core as much as many of the Spl classes. It should be clear by now that the PHP community really do want annotations. At this stage, if someone has done the work to make this happen, the discussion really should be more about polishing that contribution and making sure it provides a robust solution to this feature than trying to postpone or find reasons to put this off. *IS* it clear by now that the majority of users want this? And the argument that 'You don't have to use it' does not wash either since once it has been pushed in, some of the libraries we are using are going to start requiring it simply because those developers do like the idea, but it does not necessarily mean that THE CURRENT PROPOSAL is the right way of doing it? What I seem to have lost is the evidence that annotations are going in because we HAVE all agreed to them? If they CAN'T be implemented as a PECL extension, then they need a very good implementation covering all aspects even before it is decided that they should be pushed in? Much like Traits ... The current standards such as phpdoc are falling well behind because nobody has the time to implement some of the ALREADY created new features. It is this that is more annoying given the investment in time just to try and keep up, And creating tools intended for users who don't like the existing tools is further watering down the project :( The existing tools had been working well, but nowadays things are simply becoming a mess ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
