# 5.4 again - Thread: https://externals.io/message/52138 - Original archive: https://news-web.php.net/php.internals/52138 - Started by Stas Malyshev on 2011-05-08T23:40:30+00:00 - Messages: 104 - Page 1 of 5: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/52138.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #52138 — Stas Malyshev — 2011-05-08T23:40:30+00:00 URL: https://externals.io/message/52138#52138 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 --- ## #52139 — Rasmus Lerdorf — 2011-05-09T03:31:11+00:00 URL: https://externals.io/message/52138#52139 · In reply to: #52138 > 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. :) -Rasmus --- ## #52140 — Ferenc Kovacs — 2011-05-09T07:41:07+00:00 URL: https://externals.io/message/52138#52140 · In reply to: #52139 > > > > […] > > 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 --- ## #52141 — Stas Malyshev — 2011-05-09T07:50:17+00:00 URL: https://externals.io/message/52138#52141 · In reply to: #52140 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 --- ## #52142 — Stefan Marr — 2011-05-09T08:00:42+00:00 URL: https://externals.io/message/52138#52142 · In reply to: #52141 Hi: > 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 --- ## #52143 — Ferenc Kovacs — 2011-05-09T08:02:17+00:00 URL: https://externals.io/message/52138#52143 · In reply to: #52141 On Mon, May 9, 2011 at 9:50 AM, Stas Malyshev wrote: > Hi! > > > another thing that I would love to see on the list: named parameters. > > […] > > 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 --- ## #52144 — Ferenc Kovacs — 2011-05-09T08:04:17+00:00 URL: https://externals.io/message/52138#52144 · In reply to: #52142 > Hi: > > > > > […] > 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 --- ## #52145 — Stas Malyshev — 2011-05-09T08:38:08+00:00 URL: https://externals.io/message/52138#52145 · In reply to: #52139 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 --- ## #52147 — guilhermeblanco@gmail.com — 2011-05-09T14:44:31+00:00 URL: https://externals.io/message/52138#52147 · In reply to: #52145 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, > Hi! > > > […] > > 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 > > -- > > > > -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- ## #52148 — Martin Scotta — 2011-05-09T15:50:32+00:00 URL: https://externals.io/message/52138#52148 · In reply to: #52147 Martin Scotta On Mon, May 9, 2011 at 11:44 AM, guilhermeblanco@gmail.com < guilhermeblanco@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 > wrote: > > […] > is > > […] > > > > -- > Guilherme Blanco > Mobile: +55 (16) 9215-8480 > MSN: guilhermeblanco@hotmail.com > São Paulo - SP/Brazil --- ## #52150 — Philip Olson — 2011-05-09T16:18:08+00:00 URL: https://externals.io/message/52138#52150 · In reply to: #52145 > Hi! > > > […] > > 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 --- ## #52151 — Rasmus Lerdorf — 2011-05-09T16:44:00+00:00 URL: https://externals.io/message/52138#52151 · In reply to: #52147 > - 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 --- ## #52152 — Stas Malyshev — 2011-05-09T16:55:02+00:00 URL: https://externals.io/message/52138#52152 · In reply to: #52147 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 --- ## #52153 — Marcelo Gornstein — 2011-05-09T16:55:07+00:00 URL: https://externals.io/message/52138#52153 · In reply to: #52151 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 > > > […] > > If someone doesn't agree that annotations belong in PHP why do the details > of the patch matter? > > > […] > > 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 > > -- > > > > -- -- // 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 --- ## #52154 — Alessandro Nadalin — 2011-05-09T17:01:43+00:00 URL: https://externals.io/message/52138#52154 · In reply to: #52153 > 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 > > > > […] > > > > -- > > -- > // 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 > > -- > > > > -- Nadalin Alessandro www.odino.org www.twitter.com/_odino_ --- ## #52155 — Stas Malyshev — 2011-05-09T17:05:26+00:00 URL: https://externals.io/message/52138#52155 · In reply to: #52153 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 --- ## #52156 — Lester Caine — 2011-05-09T17:13:00+00:00 URL: https://externals.io/message/52138#52156 · In reply to: #52152 Stas Malyshev wrote: > > […] > > 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 --- ## #52157 — Marcelo Gornstein — 2011-05-09T17:19:50+00:00 URL: https://externals.io/message/52138#52157 · In reply to: #52155 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). > Hi! > > > […] > > 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 --- ## #52158 — Andi Gutmans — 2011-05-09T17:20:31+00:00 URL: https://externals.io/message/52138#52158 · In reply to: #52138 > -----Original Message----- > From: Stas Malyshev [mailto:smalyshev@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-internals&m=119999385524494&w=2. If this is what we're talking about I personally feel it's an easy one. - Agree type hints goes out. Go!! Andi --- ## #52159 — Matthew Weier O'Phinney — 2011-05-09T17:22:07+00:00 URL: https://externals.io/message/52138#52159 · In reply to: #52153 > 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 > > > > […] > > > -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc --- ## #52160 — Derick Rethans — 2011-05-09T17:22:21+00:00 URL: https://externals.io/message/52138#52160 · In reply to: #52157 > 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 --- ## #52161 — Andi Gutmans — 2011-05-09T17:22:53+00:00 URL: https://externals.io/message/52138#52161 · In reply to: #52157 > -----Original Message----- > From: Marcelo Gornstein [mailto:marcelog@gmail.com] > Sent: Monday, May 09, 2011 10:20 AM > To: Stas Malyshev > Cc: guilhermeblanco@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 --- ## #52162 — guilhermeblanco@gmail.com — 2011-05-09T17:25:51+00:00 URL: https://externals.io/message/52138#52162 · In reply to: #52151 Hi Rasmus, > > > […] > > 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. > > > […] > > 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: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- ## #52163 — Christopher Jones — 2011-05-09T17:27:54+00:00 URL: https://externals.io/message/52138#52163 · In reply to: #52147 > 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.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ --- ## #52164 — Stas Malyshev — 2011-05-09T17:30:49+00:00 URL: https://externals.io/message/52138#52164 · In reply to: #52147 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 --- Next page: https://externals.io/message/52138.md?page=2