Re: [PHP-DEV] annotations again
Am 11.05.2011 00:28, schrieb guilhermebla...@gmail.com: - Entities with knowledge about its persistence information That must be something I simply have no knowledge about. But isn't it just a theoretical difference, because in practice, the code being annotations or PHP-Code is kept within the class, therefore the entity is not separated from its persistence information...but then I don't really understand the problem in the first place;) - Resources being wasted Now you sound like Rasmus when he talks about his assembly-history. Do you really expect Annotations to perform better than hard-wired php-code? - You rely on an instance to grab information. Or you use a slow approach of having a static method This must be something else I do not know. Why is that slower? Also, there are much more things than you can actually think of related to this. The code is not bloated. Since you don't have a pre-processor for class metadatas, you have to build all definitions manually. This is why you have to set inheritance type, for example. It seems to me that with good default-behaviour, the coded needed could be stripped down to what i wrote, since it contains as much information as your annotated code. FYI, Doctrine took an year of planning an another year of careful implementation of each feature. Well it's hard to argue with that without stepping on those peoples toes, isn't it?;) Is their reasoning process public knowledge? Maybe that'd help me understand. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Hi, On Wed, May 11, 2011 at 12:41 AM, Lester Caine les...@lsces.co.uk wrote: guilhermebla...@gmail.com wrote: So, please stop saying no to every feature request that comes in and start to discuss the actual impact of each feature. I think that MY only problem with you 'adding annotations because it is missing' is simply that I've already been doing it for years - just not calling it 'annotations' ... its 'documentation' and always has been ... It is really troubling to read that statement. Seems there are still some that don't really have a clue of what annotations are, even when the RFC clearly links to them. Annotations ARE NOT documentation; in the case of PHP, documentation is being used as annotations because there is no language implementation, which exists in other languages (Java, .NET) and they are widely used. Also, some use annotations as documentation (e.g. store the class version), but again, annotations ARE NOT documentation. Don't let the @ notation shared with docblock fool you. Guilherme, I think its easy to assume that people already have some sense of what annotations are, but perhaps the wiki entry could be more educational about it?. The first time I read about annotations it was from this link: http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html; perhaps an intro like that could help to make the case for annotations crystal clear?. The real problem at present is that the whole ecosystem is now so disjointed that PHP5.2 is the last version that is still fairly fully supported, but people are pushing for 5.4 before 5.3 has been properly put to bed. We need to finish of what is already added fully before pushing more new stuff in? That INCLUDES in the ecosystem! And we still have the hole that is unicode ... This is another thing that troubles me when I read this list. How does the PHP core dev community sets priorities?, is there some sort of roadmap?, is there a process to create this roadmap?, or is it just all a generalized best intention to do things. I'm aware that the more features the more has to be maintained, but, what I see is that there is lot of potential for the core dev community to grow and at its current state it doesn't seem to be able scale due to the lack of a roadmap/process. I'm not trying to be a douche here, just saying: I see lots of criticism towards everything and very few agreements. Best regards, David Vega
Re: [PHP-DEV] annotations again
Am 10.05.2011 16:53, schrieb Martin Scotta:
Annotations are not required, you add them if you want to.
Yes. sure. But I am sure that certain Annotations must be combined to
unleash their purpose, no? There is no validation for that, correct?
Also they can be used not only with classes. You can annotate methods,
members, parameters (I'm not sure about the RFC scope)
With the interface approach you can annotate classes, methods, members
and parameters, depending on how you build it, no? Annotating functions
by themselves...is that really an issue? Since they're mostly stateless
why would they need meta-data?
with extends you inherit implementation
with traits you inherit code
With annotations you inherit behavior.
inheriting behaviour is just a special case of inheriting code as in
traits, no?
you cannot do this with interfaces
Annotation(param=Value) class Class { }
interface Annotation { function getParam(); }
and how do you apply an interface to a method?
Deprecated function getSomething() { }
interface Annotation {
function getMethodAnnotation($method){
switch( $method ) {
case 'getSomething': return array('deprecated');
}
}
}
All the framework/library boiler-plate should be reduced to minimum.
I can't argue with that.
What I just noticed is that simple examples (key=value or even just
keywords) are indeed concise and I could imagine using it this way. But
for that we have docblocs. But as soon as you go into more complex
structures, more than key=value which guilherme keeps arguing is so
essential to the Annotations and is also why we can't use docblocks, it
gets unreadable and especially for maintaining state within meta-data,
I'd always use PHP-Interfaces over Annotations.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
dukeofgaming wrote:
So, please stop saying no to every feature request that comes
in and
start to discuss the actual impact of each feature.
I think that MY only problem with you 'adding annotations because it
is missing' is simply that I've already been doing it for years -
just not calling it 'annotations' ... its 'documentation' and always
has been ...
It is really troubling to read that statement. Seems there are still
some that don't really have a clue of what annotations are, even when
the RFC clearly links to them. Annotations ARE NOT documentation; in the
case of PHP, documentation is being used as annotations because there is
no language implementation, which exists in other languages (Java, .NET)
and they are widely used. Also, some use annotations as documentation
(e.g. store the class version), but again, annotations ARE NOT
documentation. Don't let the @ notation shared with docblock fool you.
Guilherme, I think its easy to assume that people already have some
sense of what annotations are, but perhaps the wiki entry could be more
educational about it?. The first time I read about annotations it was
from this link:
http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html;
perhaps an intro like that could help to make the case for annotations
crystal clear?.
But that aligns perfectly with my interpretation of 'annotations' - compiler
time commands and control - but we do not compile - we run the files raw.
It even say ...
Documentation
Many annotations replace what would otherwise have been comments in code.
And I can't see why the @interface complexity can't simply be replaced with the
existing docblock header which already has the same data contained. However that
is only part of the picture and passing information on parameters is what I am
seeing as the main use of annotation? ( this is probably going to wrap )
/**
* registerPackageUpgrade
*
* @param array $pParams Hash of information about upgrade
* @param string $pParams[package] Name of package that is upgrading
* @param string $pParams[version] Version of this upgrade
* @param string $pParams[description] Description of what the upgrade
does
* @param string $pParams[post_upgrade] Textual note of stuff that
needs to be observed after the upgrade
* @param array $pUpgradeHash Hash of update rules. See existing
upgrades on how this works.
* @access public
* @return void
*/
function registerPackageUpgrade( $pParams, $pUpgradeHash = array() ) {
No doubt this could be automatically processed to to provide a java like view of
the same information, but what am I missing here? The data is already contained
in the code ... existing tools handle and display it ... but it is still easily
edited and read by any existing user?
Of cause doxygen requires a slightly different dialect to phpdoc, and THAT is
something that it would be worth investigating, but that is a different problem.
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
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
This is another thing that troubles me when I read this list. How does the PHP core dev community sets priorities?, is there some sort of roadmap?, is there a process to create this roadmap?, or is it just all a generalized best intention to do things. I'm aware that the more features the more has to be maintained, but, what I see is that there is lot of potential for the core dev community to grow and at its current state it doesn't seem to be able scale due to the lack of a roadmap/process. I'm not trying to be a douche here, just saying: I see lots of criticism towards everything and very few agreements. The roadmap is in the form of a feature list which you can find at wiki.php.net/etc There is never going to be complete agreement on any feature, but once there is enough agreement from the main stakeholders in a certain feature and the implementation looks feasible both from a technical perspective and from actually having someone willing to do the work, it gets assigned to a release. In the case of annotations there were some serious stakeholders, like Matthew, Sebastian and others who really do understand what annotations are and why they are needed, but they did not agree with the proposed approach. That's why we have the RFCs and that's why these discussions flare up around release time. It triggers people to take a really serious look at a feature to see how it would work for them. And yes there is a lot of noise. You will see quite a few uninformed opinions, and a few informed ones. We have always kept things completely open for anyone to have their say. This openness gives people access, but it also often gives people the sense that there is complete chaos. We are not .Net. -Rasmus
Re: [PHP-DEV] annotations again
Am 11.05.2011 09:35, schrieb dukeofgaming: Que?. Are you aware that you cannot implement interface methods?. Sorry. my bad. I mixed implementation with specification, but it would work, no? I really think the dilemma of whether annotations are useful or not is moot. What an argument. I'm not saying they are not useful. I am saying they can be done with what we already have. I've got tons of code which could run faster if the core-devs finally decided to take my aproach over theirs...;) Also citings of .NET and Java makes me wanna scream, because I don't want those languages. I want PHP, which has been my faithful servant for over 12 years! -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - THE TOOLPARK CORPORATION AG Lars Schultz Software Entwickler Bühlstrasse 1, Postfach, CH-8125 Zollikerberg-Zürich Telefon +41 44 396 26 44, Fax +41 44 391 22 60 lars.schu...@toolpark.com, http://www.toolpark.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Diese Nachricht kann vertrauliche oder rechtlich geschützte Informationen enthalten, deren Verbreitung ohne unsere ausdrückliche Erlaubnis untersagt ist. Falls Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte umgehend den Absender, vernichten diese Nachricht und unterlassen unbedingt das Veröffentlichen, Vervielfältigen oder Verbreiten sämtlicher Inhalte und Anlagen. Bitte beachten Sie, dass wir uns das Recht vorbehalten, alle ein- und ausgehenden Nachrichten zu überwachen und aufzuzeichnen. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Lars Schultz wrote: Also citings of .NET and Java makes me wanna scream, because I don't want those languages. I want PHP, which has been my faithful servant for over 12 years! Mine not quite so long, but exactly ... -- 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
On Wed, May 11, 2011 at 2:59 AM, Lars Schultz lars.schu...@toolpark.comwrote: Am 11.05.2011 09:35, schrieb dukeofgaming: Que?. Are you aware that you cannot implement interface methods?. Sorry. my bad. I mixed implementation with specification, but it would work, no? Eh, well, in a weird and complex way I'd guess =P. If it were about implementing a workaround to annotations for class metadata I'd use mixins and magic methods, but that doesn't win over annotations, not by a long shot. I really think the dilemma of whether annotations are useful or not is moot. What an argument. I'm not saying they are not useful. I am saying they can be done with what we already have. I've got tons of code which could run faster if the core-devs finally decided to take my aproach over theirs...;) Also citings of .NET and Java makes me wanna scream, because I don't want those languages. I want PHP, which has been my faithful servant for over 12 years! I rarely use Java, I personally hate .NET, and PHP is the language that has been giving me my bread and butter since I started as a developer. I'm just saying that as far as language design goes, this is not something new and it has been succesfully taken advantage of for years. Also, and if I'm not mistaken, PHP has already taken from Java's example with exceptions and the interfaces you love =P.
Re: [PHP-DEV] annotations again
Am 11.05.2011 10:11, schrieb dukeofgaming: Eh, well, in a weird and complex way I'd guess =P. I am saying that using interfaces in situations where you need more than key = value annotations or state (is that correct?) are of similar complexity and already available. Also, and if I'm not mistaken, PHP has already taken from Java's example with exceptions and the interfaces you love =P. Don't get me wrong. I don't love interfaces, I find them useful in very specific situations, especially when code needs to be reusable as in a library or framework. With 800 classes in my main project I am using 10 interfaces. Almost always in a Describing/Metadata-way. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Wed, May 11, 2011 at 2:45 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: The roadmap is in the form of a feature list which you can find at http://wiki.php.net/etcwiki.php.net/etc There is never going to be complete agreement on any feature, but once there is enough agreement from the main stakeholders in a certain feature and the implementation looks feasible both from a technical perspective and from actually having someone willing to do the work, it gets assigned to a release. The link doesn't work, but I'm assuming it is this one?: https://wiki.php.net/todo In the case of annotations there were some serious stakeholders, like Matthew, Sebastian and others who really do understand what annotations are and why they are needed, but they did not agree with the proposed approach. That's why we have the RFCs and that's why these discussions flare up around release time. It triggers people to take a really serious look at a feature to see how it would work for them. In other words, the ideal situation to move this particular case forward is to have more stakeholders join the discussion, right?. An issue that I see here is that it is not that easy to join in the discussion because: a) They would need to be already in the list to have an easy way to access all the messages b) The thread is too disperse to follow in http://news.php.net/php.internals/ c) The public mirror of the newsgroup is faulty, see http://news.php.net/php.internals/52242 for example *command too long: XPATH 4dc826b1.4090...@lerdorf.com 4dc82a36.8090...@lerdorf.com 4dc83401.2090...@sugarcrm.com 4dc8d122.3050...@lsces.co.uk 4dc8f125.2010...@toolpark.com 4dc8fb1a.7040...@lerdorf.com* My suggestion for this —and it would be a rather disruptive one, I know— is to move the lists to Google Groups, or at least create one or two as an experiment, say: php-userland and php-dev. BTW, Guilherme is an important stakeholder too, he has participated in Doctrine2 annotation-related work: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/Driver/AnnotationDriver.php And yes there is a lot of noise. You will see quite a few uninformed opinions, and a few informed ones. We have always kept things completely open for anyone to have their say. This openness gives people access, but it also often gives people the sense that there is complete chaos. We are not .Net. That I understand, respect and applaud. Still, I think a better process would provide more transparency (openness !== transparency), which is an issue I've seen others complain about. This way, people willing to implement their own feature might understand easier that if they help out with existing actionable PHP problems, the community could shift more easily their attention to their proposals. The way I see it, PHP has moved by inertia all these years, and it has worked, but I think there are measures that could be taken to lead the discussions towards a more productive path. For example, is there anyone at all that does some kind of moderation?, and I don't mean the coercive type, but the hey guys, this seems off-topic, can you start this discussion on another email thread? type of moderation. Best regards, David Vega
Re: [PHP-DEV] annotations again
On Wed, 2011-05-11 at 03:39 -0500, dukeofgaming wrote: In other words, the ideal situation to move this particular case forward is to have more stakeholders join the discussion, right?. An issue that I see here is that it is not that easy to join in the discussion because: a) They would need to be already in the list to have an easy way to access all the messages NNTP exists and nntp://news.php.net does a good job in providing the messages in a way that can be consumed by lots of different clients, web based as well as fat clients. b) The thread is too disperse to follow in http://news.php.net/php.internals/ c) The public mirror of the newsgroup is faulty, see http://news.php.net/php.internals/52242 for example *command too long: XPATH 4dc826b1.4090...@lerdorf.com 4dc82a36.8090...@lerdorf.com 4dc83401.2090...@sugarcrm.com 4dc8d122.3050...@lsces.co.uk 4dc8f125.2010...@toolpark.com 4dc8fb1a.7040...@lerdorf.com* We welcome patches for infrastructure, too :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
dukeofgaming wrote: c) The public mirror of the newsgroup is faulty, see http://news.php.net/php.internals/52242 for example /command too long: XPATH 4dc826b1.4090...@lerdorf.com mailto:4dc826b1.4090...@lerdorf.com 4dc82a36.8090...@lerdorf.com mailto:4dc82a36.8090...@lerdorf.com 4dc83401.2090...@sugarcrm.com mailto:4dc83401.2090...@sugarcrm.com4dc8d122.3050...@lsces.co.uk mailto:4dc8d122.3050...@lsces.co.uk 4dc8f125.2010...@toolpark.com mailto:4dc8f125.2010...@toolpark.com 4dc8fb1a.7040...@lerdorf.com mailto:4dc8fb1a.7040...@lerdorf.com/ The 'fix' for this one is for the list to stop requiring the use of 'reply all' and simply reply to just internals - But that is another religious war :) I've got in the habit of killing all the extra reply addresses myself! As for google ... don't expect people to follow you ... where I HAVE to reply to a google list it is short and sweet ... There again perhaps that is how the list culls 'trolls' like me ? -- 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
On 05/11/2011 01:39 AM, dukeofgaming wrote: The link doesn't work, but I'm assuming it is this one?: https://wiki.php.net/todo That was supposed to be wiki.php.net/rfc (iPad auto-correct messed it up) In other words, the ideal situation to move this particular case forward is to have more stakeholders join the discussion, right?. An issue that I see here is that it is not that easy to join in the discussion because: I don't think we need to lower the participation bar further here. It doesn't take very long to find a threaded version of the list if that is what you think is holding people back. All the lists are here, http://php.markmail.org/search/ for example. But honestly, subscribing to a mailing list and watching it for a while before participating is not too much to ask from people who want to participate. My suggestion for this —and it would be a rather disruptive one, I know— is to move the lists to Google Groups, or at least create one or two as an experiment, say: php-userland and php-dev. We have such a user list already. Many of them actually, but the main one is php-general. Again, refer to the above link where you can see that php-general gets way more traffic than the internals list, so there is no lack of participation there. BTW, Guilherme is an important stakeholder too, he has participated in Doctrine2 annotation-related work: Of course he is. But like I said, we need all the major stakeholders to reach some sort of agreement on large efforts like this. The way I see it, PHP has moved by inertia all these years, and it has worked, but I think there are measures that could be taken to lead the discussions towards a more productive path. For example, is there anyone at all that does some kind of moderation?, and I don't mean the coercive type, but the hey guys, this seems off-topic, can you start this discussion on another email thread? type of moderation. Of course. I've often sent private emails to people to politely suggest they take things offline and others regularly step in as well. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] news.php.net (was Re: [PHP-DEV] annotations again)
On Wed, 2011-05-11 at 10:21 +0100, Lester Caine wrote: dukeofgaming wrote: c) The public mirror of the newsgroup is faulty, see http://news.php.net/php.internals/52242 for example /command too long: XPATH 4dc826b1.4090...@lerdorf.com mailto:4dc826b1.4090...@lerdorf.com 4dc82a36.8090...@lerdorf.com mailto:4dc82a36.8090...@lerdorf.com 4dc83401.2090...@sugarcrm.com mailto:4dc83401.2090...@sugarcrm.com4dc8d122.3050...@lsces.co.uk mailto:4dc8d122.3050...@lsces.co.uk 4dc8f125.2010...@toolpark.com mailto:4dc8f125.2010...@toolpark.com 4dc8fb1a.7040...@lerdorf.com mailto:4dc8fb1a.7040...@lerdorf.com/ The 'fix' for this one is for the list to stop requiring the use of 'reply all' and simply reply to just internals - But that is another religious war :) No, this is not the fix. These are the message ids of the mails in the thread. The external fix would be not having such nested threads. The proper fix is in http://svn.php.net/viewvc/web/php-news/ to limit this. I've got in the habit of killing all the extra reply addresses myself! Which is bad, as it means that I don't get a reply to the sub-thread I'm interested in (as i participated) to my inbox, but only in my internals folder, where it easily disappears in a long thread. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Wed, May 11, 2011 at 4:30 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 05/11/2011 01:39 AM, dukeofgaming wrote: The link doesn't work, but I'm assuming it is this one?: https://wiki.php.net/todo That was supposed to be wiki.php.net/rfc (iPad auto-correct messed it up) I see. I have actually read most RFCs, but I do feel something is meesing. Perhaps if RFCs were categorized by potential release in the wiki —or alternatively, an additional Intented PHP version field— then agreements coud get easier, because I don't see consistent PHP version information for RFCs that could lead to an actual roadmap. I don't think we need to lower the participation bar further here. It doesn't take very long to find a threaded version of the list if that is what you think is holding people back. All the lists are here, http://php.markmail.org/search/ for example. But honestly, subscribing to a mailing list and watching it for a while before participating is not too much to ask from people who want to participate. My suggestion for this —and it would be a rather disruptive one, I know— is to move the lists to Google Groups, or at least create one or two as an experiment, say: php-userland and php-dev. We have such a user list already. Many of them actually, but the main one is php-general. Again, refer to the above link where you can see that php-general gets way more traffic than the internals list, so there is no lack of participation there. I wholeheartedly agree, but sometimes it is the small details that lead to dissuasion (e.g. having to look for the right/best mirror). In general I've found Google Groups mailing lists more approachable/usable. I see now that there are nice mirrors, but in general the mirror solution feels fragmented. Just my opinion here. BTW, Guilherme is an important stakeholder too, he has participated in Doctrine2 annotation-related work: Of course he is. But like I said, we need all the major stakeholders to reach some sort of agreement on large efforts like this. How could we get them here?. I know there is no magical answer but if we do need them here something must be done, right? (e.g. make the RFC more appealing for technical debate?). The way I see it, PHP has moved by inertia all these years, and it has worked, but I think there are measures that could be taken to lead the discussions towards a more productive path. For example, is there anyone at all that does some kind of moderation?, and I don't mean the coercive type, but the hey guys, this seems off-topic, can you start this discussion on another email thread? type of moderation. Of course. I've often sent private emails to people to politely suggest they take things offline and others regularly step in as well. But, is there such a role/responsibility/structure within the community?, and I'm really not talking about hierarchy or bureaucracy, just that I've seen it is important that there is someone that commits to such a role and not just leave it to other's good will. Best regards, David
[PHP-DEV] Re: news.php.net (was Re: [PHP-DEV] annotations again)
Johannes Schlüter wrote: I've got in the habit of killing all the extra reply addresses myself! Which is bad, as it means that I don't get a reply to the sub-thread I'm interested in (as i participated) to my inbox, but only in my internals folder, where it easily disappears in a long thread. I leave the folders on 'display unread' and only open them up if there is a need to view the history. That way I can also see which list stuff is coming in from, and don't need to later copy traffic to sub-folders? Again the ecosystem can be fundamentally different for each of us so one person's + is another's - -- 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
On 11 May 2011 07:50, dukeofgaming dukeofgam...@gmail.com wrote: It is really troubling to read that statement. Seems there are still some that don't really have a clue of what annotations are, even when the RFC clearly links to them. Annotations ARE NOT documentation; in the case of PHP, documentation is being used as annotations because there is no language implementation, which exists in other languages (Java, .NET) and they are widely used. Also, some use annotations as documentation (e.g. store the class version), but again, annotations ARE NOT documentation. Don't let the @ notation shared with docblock fool you. Guilherme, I think its easy to assume that people already have some sense of what annotations are, but perhaps the wiki entry could be more educational about it?. The first time I read about annotations it was from this link: http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html; perhaps an intro like that could help to make the case for annotations crystal clear?. I'm guessing experience and interpretation is everything here. From reading the Oracle page, to me, it seems annotations ARE documentation. It just depends upon who or what is reading them. The first line of the page ... They have no direct effect on the operation of the code they annotate. In other words, annotations are just like comments. At least in terms of what I understand the compiler does and what the runtime processing does. The use of the @ isn't a fooling (according to Oracle) ... The use of the @ symbol in both Javadoc comments and in annotations is not coincidental—they are related conceptually.. What I can't see from the link is _WHY_ annotations can't just be docblocks? Annotations and comments don't affect the code. Annotations and comments would need to be parsed to read them. I understand that caching of the annotation could be an issue. And this leads to a gap in my knowledge/understanding. Why does _this_ script need to know anything about its annotations? Especially as They have no direct effect on the operation of the code they annotate. It would seem wasteful to process dead data for no purpose in _this_ script. It only seems useful for some sort of external process reading the annotation/comment (say a documentor or a tool to build code for runtime operation). In those cases, these are one offs (ish), so caching would not seem to serve any real benefit here. Whilst I think the syntax of the annotation may be worth discussing, the annotation can surely only exist in a comment, at least with regard to PHP. And I'm guessing that the primary use of annotations within PHP would be in runtime processing, so is this really about the parsing of docblocks. I think using PHP code in a docblock (with the appropriate tag ... @annotation maybe) would cover the requirements. Possibly. Due to phpdocumentor not being updated to handle namespaces yet, annotations are also not going to work correctly there. 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] annotations again
Am 11.05.2011 13:31, schrieb Richard Quadling: On 11 May 2011 07:50, dukeofgaming dukeofgam...@gmail.com wrote: It is really troubling to read that statement. Seems there are still some that don't really have a clue of what annotations are, even when the RFC clearly links to them. Annotations ARE NOT documentation; in the case of PHP, documentation is being used as annotations because there is no language implementation, which exists in other languages (Java, .NET) and they are widely used. Also, some use annotations as documentation (e.g. store the class version), but again, annotations ARE NOT documentation. Don't let the @ notation shared with docblock fool you. Guilherme, I think its easy to assume that people already have some sense of what annotations are, but perhaps the wiki entry could be more educational about it?. The first time I read about annotations it was from this link: http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html; perhaps an intro like that could help to make the case for annotations crystal clear?. I'm guessing experience and interpretation is everything here. From reading the Oracle page, to me, it seems annotations ARE documentation. It just depends upon who or what is reading them. The first line of the page ... They have no direct effect on the operation of the code they annotate. In other words, annotations are just like comments. At least in terms of what I understand the compiler does and what the runtime processing does. They have no direct affect of the operation of the code they annotate, but they have affect of the code which runs the annotated code. So annotations are no comments. The use of the @ isn't a fooling (according to Oracle) ... The use of the @ symbol in both Javadoc comments and in annotations is not coincidental—they are related conceptually.. I think the usage of the @ is historical. Because Java annotations in the first implementation were DocBlock annotations parsed by XDocklet. Starting with version 5 of the Java specification, they implemented Annotations as part of the language. http://www.devx.com/Java/Article/27235 What I can't see from the link is _WHY_ annotations can't just be docblocks? Annotations and comments don't affect the code. Annotations and comments would need to be parsed to read them. I understand that caching of the annotation could be an issue. And this leads to a gap in my knowledge/understanding. Why does _this_ script need to know anything about its annotations? Especially as They have no direct effect on the operation of the code they annotate. It would seem wasteful to process dead data for no purpose in _this_ script. It only seems useful for some sort of external process reading the annotation/comment (say a documentor or a tool to build code for runtime operation). In those cases, these are one offs (ish), so caching would not seem to serve any real benefit here. Whilst I think the syntax of the annotation may be worth discussing, the annotation can surely only exist in a comment, at least with regard to PHP. And I'm guessing that the primary use of annotations within PHP would be in runtime processing, so is this really about the parsing of docblocks. I think using PHP code in a docblock (with the appropriate tag ... @annotation maybe) would cover the requirements. Possibly. Due to phpdocumentor not being updated to handle namespaces yet, annotations are also not going to work correctly there. Richard. Why not learning from Java and implement annotations in the way Guilherme proposed it? I think they had good reasons for the new implementation. Maybe someone has a link which points to such discussion. Best regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 11 May 2011 18:07, Christian Kaps christian.k...@mohiva.com wrote: Why not learning from Java and implement annotations in the way Guilherme proposed it? I think they had good reasons for the new implementation. Maybe someone has a link which points to such discussion. I believe you are looking for something like this http://www.jcp.org/en/jsr/detail?id=250 and possibly others like JSR 175 and 308 There are a few others (google: JSR annotations). Regards, Drak -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 05/10/2011 10:03 PM, Chad Fulton wrote: On Tue, May 10, 2011 at 12:35 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi all, Based on an extensive chat with Matthew, I think we reached some consensus. I'll write another RFC related to Annotations in docblocks, then we can chat until reach some standardization and availability. I'll keep the old one for history purposes. It seems that none from core php devs accepted it, so I'll move it to rejected. As I told you previously, all I wanted was some good feedback to give a north and that's what I had. As soon as I finish the new RFC, I'll open another thread here for fine-grain the support and discuss architecture. I'll keep Stas comments in mind when creating it, so it would help in discussions. It seems we still have 2 weeks to discuss the new idea and less than 2 months to get it ready if everyone agreed. Please first take a look at the current RFC regarding parsing docblocks: https://wiki.php.net/rfc/docblockparser . Even if you want to put up a competing RFC, at least you can use it as a point of reference. Chad Additionally I would recommend reading the JavaDoc and phpDocumentor rules concerning DocBlocks. As far as I can see the RFC mentioned above is incomplete with respect to the current syntax guidelines for DocBlocks as mentioned in the documents above; which is used for quite a bit of projects out there. I'll keep my eyes open for the new RFC to see if I can contribute some of my experiences to the efforts. I hope that my experiences building the Static Reflection for DocBlocks in DocBlox can prove useful. -- Mike van Riel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Wed, May 11, 2011 at 2:36 PM, Mike van Riel mike.vanr...@naenius.comwrote: On 05/10/2011 10:03 PM, Chad Fulton wrote: On Tue, May 10, 2011 at 12:35 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi all, Based on an extensive chat with Matthew, I think we reached some consensus. I'll write another RFC related to Annotations in docblocks, then we can chat until reach some standardization and availability. I'll keep the old one for history purposes. It seems that none from core php devs accepted it, so I'll move it to rejected. As I told you previously, all I wanted was some good feedback to give a north and that's what I had. As soon as I finish the new RFC, I'll open another thread here for fine-grain the support and discuss architecture. I'll keep Stas comments in mind when creating it, so it would help in discussions. It seems we still have 2 weeks to discuss the new idea and less than 2 months to get it ready if everyone agreed. Please first take a look at the current RFC regarding parsing docblocks: https://wiki.php.net/rfc/docblockparser . Even if you want to put up a competing RFC, at least you can use it as a point of reference. Chad Additionally I would recommend reading the JavaDoc and phpDocumentor rules concerning DocBlocks. As far as I can see the RFC mentioned above is incomplete with respect to the current syntax guidelines for DocBlocks as mentioned in the documents above; which is used for quite a bit of projects out there. I'll keep my eyes open for the new RFC to see if I can contribute some of my experiences to the efforts. I hope that my experiences building the Static Reflection for DocBlocks in DocBlox can prove useful. as phpDocumentor is dead and doesn't support new things like namespace and closures, we should take those into account also. Tyrael
Re: [PHP-DEV] annotations again
Ferenc Kovacs wrote: as phpDocumentor is dead and doesn't support new things like namespace and closures, we should take those into account also. Nothing stops it from working perfectly well on the years of code that it still supports! Finding people with the time to ADD new features is the problem especially when they are not currently using those new features themselves. It is one of the packages that I have managed some patches on myself, but some of it's esoteric ways of working make contributing a little difficult. What do you suggest as an alternative - is there any? -- 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
On 05/11/2011 03:18 PM, Lester Caine wrote: Ferenc Kovacs wrote: as phpDocumentor is dead and doesn't support new things like namespace and closures, we should take those into account also. Nothing stops it from working perfectly well on the years of code that it still supports! Finding people with the time to ADD new features is the problem especially when they are not currently using those new features themselves. It is one of the packages that I have managed some patches on myself, but some of it's esoteric ways of working make contributing a little difficult. What do you suggest as an alternative - is there any? DocBlox (http://www.docblox-project.org) is a rising project which offers support for all these new things and uses less processing time and memory. It is goal is to serve as an alternative for phpDocumentor (and an improvement, it has several features of it's own such as incremental parsing). DISCLAIMER: I am the Lead Dev of DocBlox. (and before you asked: yes I tried patching phpDocumentor but its core design would not allow enough room to patch the memory and performance problems, which prevented me from running it at our own project) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Wed, May 11, 2011 at 3:27 PM, Mike van Riel mike.vanr...@naenius.comwrote: On 05/11/2011 03:18 PM, Lester Caine wrote: Ferenc Kovacs wrote: as phpDocumentor is dead and doesn't support new things like namespace and closures, we should take those into account also. Nothing stops it from working perfectly well on the years of code that it still supports! Finding people with the time to ADD new features is the problem especially when they are not currently using those new features themselves. It is one of the packages that I have managed some patches on myself, but some of it's esoteric ways of working make contributing a little difficult. What do you suggest as an alternative - is there any? DocBlox (http://www.docblox-project.org) is a rising project which offers support for all these new things and uses less processing time and memory. It is goal is to serve as an alternative for phpDocumentor (and an improvement, it has several features of it's own such as incremental parsing). DISCLAIMER: I am the Lead Dev of DocBlox. (and before you asked: yes I tried patching phpDocumentor but its core design would not allow enough room to patch the memory and performance problems, which prevented me from running it at our own project) I would also suggest DocBlox, pretty alive project, open for feedbacks (contributed some ideas myself), and Zend Framework started using it, so now it has a pretty nice userbase. Tyrael
Re: [PHP-DEV] annotations again
Mike van Riel wrote: DocBlox (http://www.docblox-project.org) is a rising project which offers support for all these new things and uses less processing time and memory. It is goal is to serve as an alternative for phpDocumentor (and an improvement, it has several features of it's own such as incremental parsing). DISCLAIMER: I am the Lead Dev of DocBlox. (and before you asked: yes I tried patching phpDocumentor but its core design would not allow enough room to patch the memory and performance problems, which prevented me from running it at our own project) I'll hit the bitweaver code with it and see what I get ;) Takes about 45 minutes with phpdoc but I needed 8Gb of memory to get it to run :) -- 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
On 2011-05-11, dukeofgaming dukeofgam...@gmail.com wrote: On Wed, May 11, 2011 at 12:41 AM, Lester Caine les...@lsces.co.uk wrote: guilhermebla...@gmail.com wrote: So, please stop saying no to every feature request that comes in and start to discuss the actual impact of each feature. I think that MY only problem with you 'adding annotations because it is missing' is simply that I've already been doing it for years - just not calling it 'annotations' ... its 'documentation' and always has been ... It is really troubling to read that statement. Seems there are still some that don't really have a clue of what annotations are, even when the RFC clearly links to them. Annotations ARE NOT documentation; in the case of PHP, documentation is being used as annotations because there is no language implementation, which exists in other languages (Java, .NET) and they are widely used. Also, some use annotations as documentation (e.g. store the class version), but again, annotations ARE NOT documentation. Don't let the @ notation shared with docblock fool you. That may be the case. However, annotations within docblocks have been the de facto standard for going on a decade. Adding a new language feature at this point means several things: * Developers using annotations in docblocks now need to consider migrating to true annotations, which in turn means... * BC break of their code with previous versions of PHP. * In many cases, not only are code changes needed (moving annotations out of docblocks), but also likely the code handling the annotations will need to be updated -- which means at least one if not several maintenance cycles. Expensive. * And don't forget the cases where docblock annotations were serving multiple purposes. A good example: ZF server classes utilize the same docblock annotations used by phpDocumentor (well, now DocBlox!) in order to deliver method signatures to clients. Switching to annotations would end up duplicating information in this use case. The point that myself and others have been trying to make is that we may agree with the need for annotations, but due to the long-standing history of using annotations in docblocks, coupled with the desire to reduce potential BC breaks and maintenance cycles, we'd prefer to see an annotation parser for docblocks vs a new language syntax. Guilherme, I think its easy to assume that people already have some sense of what annotations are, but perhaps the wiki entry could be more educational about it?. The first time I read about annotations it was from this link: http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html; perhaps an intro like that could help to make the case for annotations crystal clear?. The real problem at present is that the whole ecosystem is now so disjointed that PHP5.2 is the last version that is still fairly fully supported, but people are pushing for 5.4 before 5.3 has been properly put to bed. We need to finish of what is already added fully before pushing more new stuff in? That INCLUDES in the ecosystem! And we still have the hole that is unicode ... This is another thing that troubles me when I read this list. How does the PHP core dev community sets priorities?, is there some sort of roadmap?, is there a process to create this roadmap?, or is it just all a generalized best intention to do things. I'm aware that the more features the more has to be maintained, but, what I see is that there is lot of potential for the core dev community to grow and at its current state it doesn't seem to be able scale due to the lack of a roadmap/process. I'm not trying to be a douche here, just saying: I see lots of criticism towards everything and very few agreements. Best regards, David Vega --0016e6d260d294be9504a2fa7db4-- -- 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 2011-05-11, Lester Caine les...@lsces.co.uk wrote: Mike van Riel wrote: DocBlox (http://www.docblox-project.org) is a rising project which offers support for all these new things and uses less processing time and memory. It is goal is to serve as an alternative for phpDocumentor (and an improvement, it has several features of it's own such as incremental parsing). DISCLAIMER: I am the Lead Dev of DocBlox. (and before you asked: yes I tried patching phpDocumentor but its core design would not allow enough room to patch the memory and performance problems, which prevented me from running it at our own project) I'll hit the bitweaver code with it and see what I get ;) Takes about 45 minutes with phpdoc but I needed 8Gb of memory to get it to run :) ZF docs were taking between 80 and 110 minutes with phpDocumentor, and consuming ~2GB of RAM. They now take around 10 minutes and consume less than 1GB of RAM. :) -- 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 May 11, 2011, at 4:00 AM, dukeofgaming dukeofgam...@gmail.com wrote: On Wed, May 11, 2011 at 4:30 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 05/11/2011 01:39 AM, dukeofgaming wrote: The link doesn't work, but I'm assuming it is this one?: https://wiki.php.net/todo That was supposed to be wiki.php.net/rfc (iPad auto-correct messed it up) I see. I have actually read most RFCs, but I do feel something is meesing. Perhaps if RFCs were categorized by potential release in the wiki —or alternatively, an additional Intented PHP version field— then agreements coud get easier, because I don't see consistent PHP version information for RFCs that could lead to an actual roadmap. snip Agreed, the RFC wiki namespace is cluttered, and for example year[s] old empty entries even exist there Apply for a wiki account, then start hacking :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Hi Larz,
On Wed, May 11, 2011 at 4:02 AM, Lars Schultz lars.schu...@toolpark.com wrote:
Am 10.05.2011 16:53, schrieb Martin Scotta:
Annotations are not required, you add them if you want to.
Yes. sure. But I am sure that certain Annotations must be combined to
unleash their purpose, no? There is no validation for that, correct?
The patch does all compile time and runtime validations, so your
assertion is not valid.
Also they can be used not only with classes. You can annotate methods,
members, parameters (I'm not sure about the RFC scope)
With the interface approach you can annotate classes, methods, members and
parameters, depending on how you build it, no? Annotating functions by
themselves...is that really an issue? Since they're mostly stateless why
would they need meta-data?
with extends you inherit implementation
with traits you inherit code
With annotations you inherit behavior.
inheriting behaviour is just a special case of inheriting code as in
traits, no?
you cannot do this with interfaces
Annotation(param=Value) class Class { }
interface Annotation { function getParam(); }
and how do you apply an interface to a method?
Deprecated function getSomething() { }
interface Annotation {
function getMethodAnnotation($method){
switch( $method ) {
case 'getSomething': return array('deprecated');
}
}
}
All the framework/library boiler-plate should be reduced to minimum.
I can't argue with that.
What I just noticed is that simple examples (key=value or even just
keywords) are indeed concise and I could imagine using it this way. But for
that we have docblocs. But as soon as you go into more complex structures,
more than key=value which guilherme keeps arguing is so essential to the
Annotations and is also why we can't use docblocks, it gets unreadable and
especially for maintaining state within meta-data, I'd always use
PHP-Interfaces over Annotations.
If you tell me that you're doing this:
class User implements PersistenceEntity
{
// ...
}
You're coupling your Entity to an individual persistence tool.
This means you have a huge problem, because you're coupling things
that should be separated. This breaks the clean separation of concerns
that OO brings to us.
--
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] annotations again
Hi Lester, On Tue, May 10, 2011 at 6:32 PM, Lester Caine les...@lsces.co.uk wrote: Ferenc Kovacs wrote: sorry my FUD counter just overflowed with your last comment. Sorry you feel that way, but obviously there are more people with my view that we simply do not agree on IF annotation should be implemented. I'm a lot more comfortable with something that works WITH what we already have rather than going off on yet another tangent. Tidying existing docblock content to an updated format makes a lot more sense then having to do a wholesale re-write many thousands of files. Adding another copy of much of the same data in a complete different format is equally insane? Documentation != Annotation. A documentation is something that is human readable and understandable bu humans, but not for applications. An annotation is a behavioral functionality that is between human readable and machine readable. It's the starting point for AOP, which allows you to intercept execution. I won't enter in details because I assume you have enough experience to know how does it work. PDO is another case in point - that is still not accepted and fully functional as a replacement for the genric drivers ... ADOdb still provides a valid abstraction layer, and if you must use PDO then it just loads that instead of the generic one ... and it runs just as fast on either. PDO is functional, but needs more work, however there are few people that find the need for improving it? PDO is horrible. You have to implement workarounds for almost every driver For example Oracle driver... I already reported to Chris tons of issues (bug ids) that even include patches for each situation and I saw a *VERY* few bugs fixed. I know he has priorities and etc, but it seems that you flood your mouth to talk about PDO, but actually, writing abstraction drivers around it is very painful. -- 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] annotations again
Hi Rasmus, On Wed, May 11, 2011 at 6:30 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 05/11/2011 01:39 AM, dukeofgaming wrote: The link doesn't work, but I'm assuming it is this one?: https://wiki.php.net/todo That was supposed to be wiki.php.net/rfc (iPad auto-correct messed it up) In other words, the ideal situation to move this particular case forward is to have more stakeholders join the discussion, right?. An issue that I see here is that it is not that easy to join in the discussion because: I don't think we need to lower the participation bar further here. It doesn't take very long to find a threaded version of the list if that is what you think is holding people back. All the lists are here, http://php.markmail.org/search/ for example. But honestly, subscribing to a mailing list and watching it for a while before participating is not too much to ask from people who want to participate. My suggestion for this —and it would be a rather disruptive one, I know— is to move the lists to Google Groups, or at least create one or two as an experiment, say: php-userland and php-dev. We have such a user list already. Many of them actually, but the main one is php-general. Again, refer to the above link where you can see that php-general gets way more traffic than the internals list, so there is no lack of participation there. BTW, Guilherme is an important stakeholder too, he has participated in Doctrine2 annotation-related work: Of course he is. But like I said, we need all the major stakeholders to reach some sort of agreement on large efforts like this. The only point that I see here is that none of them heavily rely on this feature. Doctrine/Symfony relies a lot on it, and requires special treatment that key = value support is not enough. Please check out these pages for reference: Doctrine 2 Association mapping: http://www.doctrine-project.org/docs/orm/2.0/en/reference/association-mapping.html#mapping-defaults Symfony 2 Validation mapping (click on Annotations tab): http://symfony.com/doc/current/book/validation.html#constraint-configuration That's the point that I'd like to illustrate. PHP still lack of standardization in so many places. That's why I took the most complete approach that could fit in every library I've looked at. All I just don't want is to implement a docblock solution that in next major becomes a separate thing as happened to Java. My first patch (and I dunno if you remember) was around 80% compatible with JSR-250, which was carefully planned and discussed by Java folks. Of course it was a different implementation, without extra burden and with the inclusion of other powerful artifacts. Now I'm going to release another RFC for Annotations within docblocks, but I would really hope that you understand the needs of complex support instead of a key/value one. The way I see it, PHP has moved by inertia all these years, and it has worked, but I think there are measures that could be taken to lead the discussions towards a more productive path. For example, is there anyone at all that does some kind of moderation?, and I don't mean the coercive type, but the hey guys, this seems off-topic, can you start this discussion on another email thread? type of moderation. Of course. I've often sent private emails to people to politely suggest they take things offline and others regularly step in as well. -Rasmus -- 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] annotations again
guilhermebla...@gmail.com wrote: PDO is another case in point - that is still not accepted and fully functional as a replacement for the genric drivers ... ADOdb still provides a valid abstraction layer, and if you must use PDO then it just loads that instead of the generic one ... and it runs just as fast on either. PDO is functional, but needs more work, however there are few people that find the need for improving it? PDO is horrible. You have to implement workarounds for almost every driver For example Oracle driver... I already reported to Chris tons of issues (bug ids) that even include patches for each situation and I saw a *VERY* few bugs fixed. I know he has priorities and etc, but it seems that you flood your mouth to talk about PDO, but actually, writing abstraction drivers around it is very painful. For the Oracle Database, Oracle contributes to and recommends the OCI8 extension. We don't contribute to PDO_OCI. Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 05/11/2011 09:21 AM, guilhermebla...@gmail.com wrote: The only point that I see here is that none of them heavily rely on this feature. Doctrine/Symfony relies a lot on it, and requires special treatment that key = value support is not enough. Please check out these pages for reference: Doctrine 2 Association mapping: http://www.doctrine-project.org/docs/orm/2.0/en/reference/association-mapping.html#mapping-defaults Symfony 2 Validation mapping (click on Annotations tab): http://symfony.com/doc/current/book/validation.html#constraint-configuration That's the point that I'd like to illustrate. PHP still lack of standardization in so many places. That's why I took the most complete approach that could fit in every library I've looked at. All I just don't want is to implement a docblock solution that in next major becomes a separate thing as happened to Java. My first patch (and I dunno if you remember) was around 80% compatible with JSR-250, which was carefully planned and discussed by Java folks. Of course it was a different implementation, without extra burden and with the inclusion of other powerful artifacts. Now I'm going to release another RFC for Annotations within docblocks, but I would really hope that you understand the needs of complex support instead of a key/value one. My main concern is the trickle-down effect a major low-level engine addition causes. Your patch is just the tip of the iceberg which will cause dozens of people weeks of work to account for the new code all across the PHP ecosystem. The most complicated being the opcode cache support which really only can be written by a handful of people due to the complexity involved. Combine that with the fact that other projects who currently use annotations, perhaps not to the level of Doctrine, but still, state that they would have a hard time switching to this new approach it becomes really hard to commit all these people and all this time to this. We are severely resource-constrained when it comes to people who can write solid low-level C code and we have to be very careful what we ask our volunteers to spend their time on. A volunteer developer who isn't excited about a feature is going to drag her feet and it will sit solidly at the bottom of the priority list for months, if not years. If a key piece of the eco-system isn't updated because of this one addition, it means that potential PHP 5.4 users may have to wait 6, 12, 18 months before they can migrate to the new version. Therefore, low-level engine changes, syntax additions, or entirely new grammars as is the case here, face an uphill battle. If there is a way to currently solve the problem without major changes, even if it is an 80% solution that will weigh heavily against accepting the new code. Without broad support and enthusiasm, especially from the people who have historically been the ones that write the code and track down and fix the bugs, low-level features like this are doomed, no matter how well-intentioned they are. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
guilhermebla...@gmail.com wrote: Hi Lester, On Tue, May 10, 2011 at 6:32 PM, Lester Caineles...@lsces.co.uk wrote: Ferenc Kovacs wrote: sorry my FUD counter just overflowed with your last comment. Sorry you feel that way, but obviously there are more people with my view that we simply do not agree on IF annotation should be implemented. I'm a lot more comfortable with something that works WITH what we already have rather than going off on yet another tangent. Tidying existing docblock content to an updated format makes a lot more sense then having to do a wholesale re-write many thousands of files. Adding another copy of much of the same data in a complete different format is equally insane? Documentation != Annotation. A documentation is something that is human readable and understandable bu humans, but not for applications. An annotation is a behavioral functionality that is between human readable and machine readable. It's the starting point for AOP, which allows you to intercept execution. I won't enter in details because I assume you have enough experience to know how does it work. I feel that enough people have explained why the current docblock standard should not be replaced by yet another layer, but I have yet to see something 'annotation' related that has not already been used for several years within the docblock wrapper format. I come from BCB where compiler commands have always been in comments so it's natural for me anyway. PDO is another case in point - that is still not accepted and fully functional as a replacement for the genric drivers ... ADOdb still provides a valid abstraction layer, and if you must use PDO then it just loads that instead of the generic one ... and it runs just as fast on either. PDO is functional, but needs more work, however there are few people that find the need for improving it? PDO is horrible. You have to implement workarounds for almost every driver For example Oracle driver... I already reported to Chris tons of issues (bug ids) that even include patches for each situation and I saw a *VERY* few bugs fixed. I know he has priorities and etc, but it seems that you flood your mouth to talk about PDO, but actually, writing abstraction drivers around it is very painful. Something we can agree on! PDO was never the right solution to any problem, and had the time been spent on bringing the ADOdb accelerator code into PHP properly I can't help feeling we would have something much better today. I still use ADOdb and have since day one, and cringe when people ask why it hasn't been replaced by PDO ... when I can run the same test suite in ADOdb using a native and the equivalent PDO driver then things may be better, but you still need ADOdb to handle the SQL abstraction anyway. -- 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
Hi Larz, On Wed, May 11, 2011 at 3:35 AM, Lars Schultz lars.schu...@toolpark.com wrote: Am 11.05.2011 00:28, schrieb guilhermebla...@gmail.com: - Entities with knowledge about its persistence information That must be something I simply have no knowledge about. But isn't it just a theoretical difference, because in practice, the code being annotations or PHP-Code is kept within the class, therefore the entity is not separated from its persistence information...but then I don't really understand the problem in the first place;) I hope you have OO architecture knowledge. By having entity implementing an interface/abstract class, you make your domain classes depending on persistence package. This dependency breaks OO encapsulation of packages. By having the code (annotations) within the class you just meta classify each property/method of your class. You probably don't know, but annotations that you use in Doctrine follows a standard document usually referred as JPA (or JSR-317), second version. So, you may be surprised, but any persistence tool that follows this document would be able to support this Entity. One good example is how ORM package of Doctrine works and you're able to have your Entity schemaless with almost 0 changes in ODM package (read as CouchDB and MongoDB). - Resources being wasted Now you sound like Rasmus when he talks about his assembly-history. Do you really expect Annotations to perform better than hard-wired php-code? Yes, and built-in support is WAY faster. - You rely on an instance to grab information. Or you use a slow approach of having a static method This must be something else I do not know. Why is that slower? You should ask to php folks why static methods are slower than instance methods. =) Also, there are much more things than you can actually think of related to this. The code is not bloated. Since you don't have a pre-processor for class metadatas, you have to build all definitions manually. This is why you have to set inheritance type, for example. It seems to me that with good default-behaviour, the coded needed could be stripped down to what i wrote, since it contains as much information as your annotated code. FYI, Doctrine took an year of planning an another year of careful implementation of each feature. Well it's hard to argue with that without stepping on those peoples toes, isn't it?;) Is their reasoning process public knowledge? Maybe that'd help me understand. github is there for you to trace the development implementations. Also we used to have svn too. Initial commits started as soon as php 5.3 were stated. We had an almost usable PR at the time of 5.3 was not even released. =) -- 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] annotations again
On Wed, May 11, 2011 at 11:59 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: My main concern is the trickle-down effect a major low-level engine addition causes. Your patch is just the tip of the iceberg which will cause dozens of people weeks of work to account for the new code all across the PHP ecosystem. The most complicated being the opcode cache support which really only can be written by a handful of people due to the complexity involved. Combine that with the fact that other projects who currently use annotations, perhaps not to the level of Doctrine, but still, state that they would have a hard time switching to this new approach it becomes really hard to commit all these people and all this time to this. We are severely resource-constrained when it comes to people who can write solid low-level C code and we have to be very careful what we ask our volunteers to spend their time on. A volunteer developer who isn't excited about a feature is going to drag her feet and it will sit solidly at the bottom of the priority list for months, if not years. If a key piece of the eco-system isn't updated because of this one addition, it means that potential PHP 5.4 users may have to wait 6, 12, 18 months before they can migrate to the new version. Therefore, low-level engine changes, syntax additions, or entirely new grammars as is the case here, face an uphill battle. If there is a way to currently solve the problem without major changes, even if it is an 80% solution that will weigh heavily against accepting the new code. Without broad support and enthusiasm, especially from the people who have historically been the ones that write the code and track down and fix the bugs, low-level features like this are doomed, no matter how well-intentioned they are. That explanation sheds a lot of light on the general situation, thanks. Something I wanted to ask —regarding resources— is, is GSOC being leveraged this year in any way?. I'm guessing there could be lots of enthusiasm packed there, perhanos not that much for C writing, but for clearing the way for C writers.
Re: [PHP-DEV] annotations again
On 05/11/2011 02:52 PM, Ferenc Kovacs wrote: as phpDocumentor is dead and doesn't support new things like namespace and closures, we should take those into account also. Next generation documentation tools such as phpdox [1] handle these newer language features just fine. -- [1] https://github.com/theseer/phpdox -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 05/11/2011 05:32 PM, Matthew Weier O'Phinney wrote: ZF docs were taking between 80 and 110 minutes with phpDocumentor, and consuming ~2GB of RAM. They now take around 10 minutes and consume less than 1GB of RAM. :) phpdox generates documentation for Zend Framework in less than two minutes using less than 50 megabytes of memory ;-) -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 05/11/2011 11:01 PM, Sebastian Bergmann wrote: phpdox generates documentation for Zend Framework in less than two minutes using less than 50 megabytes of memory ;-) I forgot to mention that the above is for a run without an existing cache. With an existing cache it is 5 seconds and 5 megabytes. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 05/11/2011 11:05 PM, Sebastian Bergmann wrote: On 05/11/2011 11:01 PM, Sebastian Bergmann wrote: phpdox generates documentation for Zend Framework in less than two minutes using less than 50 megabytes of memory ;-) I forgot to mention that the above is for a run without an existing cache. With an existing cache it is 5 seconds and 5 megabytes. It's good to hear that Arne is making such fine progress; those are nice stats. Is this including or excluding transforming the reflector output to a full documentation site? (Perhaps best to answer off-group to reduce off-topic 'chatter'?) Allow me to showcase more detailed stats of my own for completeness (then I will stop going off-topic unless requested ;)): A full parse including the generation of a full website takes 9.2 minutes and 44.8M RAM. An incremental parse (which you call cache?) takes 3.3 minutes and 42.51M RAM. -- Mike van Riel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Wed, May 11, 2011 at 12:29 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi Larz, On Wed, May 11, 2011 at 3:35 AM, Lars Schultz lars.schu...@toolpark.com wrote: Am 11.05.2011 00:28, schrieb guilhermebla...@gmail.com: - Entities with knowledge about its persistence information That must be something I simply have no knowledge about. But isn't it just a theoretical difference, because in practice, the code being annotations or PHP-Code is kept within the class, therefore the entity is not separated from its persistence information...but then I don't really understand the problem in the first place;) I hope you have OO architecture knowledge. By having entity implementing an interface/abstract class, you make your domain classes depending on persistence package. This dependency breaks OO encapsulation of packages. By having the code (annotations) within the class you just meta classify each property/method of your class. You probably don't know, but annotations that you use in Doctrine follows a standard document usually referred as JPA (or JSR-317), second version. So, you may be surprised, but any persistence tool that follows this document would be able to support this Entity. One good example is how ORM package of Doctrine works and you're able to have your Entity schemaless with almost 0 changes in ODM package (read as CouchDB and MongoDB). I think part of the problem on the discussion —regarding the acceptance of the feature— is that annotations are being seen just as a cute feature, instead of an architectural advantage to all good PHP code (i.e. OO taking advantage of design patterns) and its implications. In summary: they are huge. If simple reflection can tell the developers what the code is, annotations let them know what it can be in depending on their context (i.e. behavior is decoupled). - Resources being wasted Now you sound like Rasmus when he talks about his assembly-history. Do you really expect Annotations to perform better than hard-wired php-code? Yes, and built-in support is WAY faster. If I'm not mistaken, the current comment-parsing solutions are so slow that the annotated classes and methods and attributes *NEED* the metadata to be cached in separate PHP code in order to function, otherwise it would be practically impossible to use them in production sites; conversely, if they were supported natively caching would not be absolutely necessary. Is this the case?, if so, I think it is a strong use case to be considered for the RFC. BTW, why is it rejected in the wiki now?. Is it completely completely rejected?, or just postponed?... if it is just cataloged as declined for now, perhaps it will be harder to retake for discussion later if it appears as declined?.
Re: [PHP-DEV] annotations again
Hi duke, I moved it to rejected in pro of a new proposal. I briefly drafted it here: https://wiki.php.net/rfc/annotations-in-docblock There's a lot of things to be officially defined, but basic idea is there. I expect to have a chat with interested core devs to see what can be done in this subject and find some common sense. =) Cheers, On Wed, May 11, 2011 at 6:54 PM, dukeofgaming dukeofgam...@gmail.com wrote: On Wed, May 11, 2011 at 12:29 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi Larz, On Wed, May 11, 2011 at 3:35 AM, Lars Schultz lars.schu...@toolpark.com wrote: Am 11.05.2011 00:28, schrieb guilhermebla...@gmail.com: - Entities with knowledge about its persistence information That must be something I simply have no knowledge about. But isn't it just a theoretical difference, because in practice, the code being annotations or PHP-Code is kept within the class, therefore the entity is not separated from its persistence information...but then I don't really understand the problem in the first place;) I hope you have OO architecture knowledge. By having entity implementing an interface/abstract class, you make your domain classes depending on persistence package. This dependency breaks OO encapsulation of packages. By having the code (annotations) within the class you just meta classify each property/method of your class. You probably don't know, but annotations that you use in Doctrine follows a standard document usually referred as JPA (or JSR-317), second version. So, you may be surprised, but any persistence tool that follows this document would be able to support this Entity. One good example is how ORM package of Doctrine works and you're able to have your Entity schemaless with almost 0 changes in ODM package (read as CouchDB and MongoDB). I think part of the problem on the discussion —regarding the acceptance of the feature— is that annotations are being seen just as a cute feature, instead of an architectural advantage to all good PHP code (i.e. OO taking advantage of design patterns) and its implications. In summary: they are huge. If simple reflection can tell the developers what the code is, annotations let them know what it can be in depending on their context (i.e. behavior is decoupled). - Resources being wasted Now you sound like Rasmus when he talks about his assembly-history. Do you really expect Annotations to perform better than hard-wired php-code? Yes, and built-in support is WAY faster. If I'm not mistaken, the current comment-parsing solutions are so slow that the annotated classes and methods and attributes *NEED* the metadata to be cached in separate PHP code in order to function, otherwise it would be practically impossible to use them in production sites; conversely, if they were supported natively caching would not be absolutely necessary. Is this the case?, if so, I think it is a strong use case to be considered for the RFC. BTW, why is it rejected in the wiki now?. Is it completely completely rejected?, or just postponed?... if it is just cataloged as declined for now, perhaps it will be harder to retake for discussion later if it appears as declined?. -- 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
is there any chance to add docblocks to arguments in methods and
global functions so annotations can be used for them? i.e:
public function aMethod(/** @Validate */ UserData $data) {
...
}
On Wed, May 11, 2011 at 6:57 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi duke,
I moved it to rejected in pro of a new proposal.
I briefly drafted it here: https://wiki.php.net/rfc/annotations-in-docblock
There's a lot of things to be officially defined, but basic idea is there.
I expect to have a chat with interested core devs to see what can be
done in this subject and find some common sense. =)
Cheers,
On Wed, May 11, 2011 at 6:54 PM, dukeofgaming dukeofgam...@gmail.com wrote:
On Wed, May 11, 2011 at 12:29 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi Larz,
On Wed, May 11, 2011 at 3:35 AM, Lars Schultz lars.schu...@toolpark.com
wrote:
Am 11.05.2011 00:28, schrieb guilhermebla...@gmail.com:
- Entities with knowledge about its persistence information
That must be something I simply have no knowledge about. But isn't it
just a
theoretical difference, because in practice, the code being
annotations or
PHP-Code is kept within the class, therefore the entity is not separated
from its persistence information...but then I don't really understand
the
problem in the first place;)
I hope you have OO architecture knowledge.
By having entity implementing an interface/abstract class, you make
your domain classes depending on persistence package.
This dependency breaks OO encapsulation of packages.
By having the code (annotations) within the class you just meta
classify each property/method of your class.
You probably don't know, but annotations that you use in Doctrine
follows a standard document usually referred as JPA (or JSR-317),
second version.
So, you may be surprised, but any persistence tool that follows this
document would be able to support this Entity. One good example is how
ORM package of Doctrine works and you're able to have your Entity
schemaless with almost 0 changes in ODM package (read as CouchDB and
MongoDB).
I think part of the problem on the discussion —regarding the acceptance of
the feature— is that annotations are being seen just as a cute feature,
instead of an architectural advantage to all good PHP code (i.e. OO taking
advantage of design patterns) and its implications. In summary: they are
huge. If simple reflection can tell the developers what the code is,
annotations let them know what it can be in depending on their context (i.e.
behavior is decoupled).
- Resources being wasted
Now you sound like Rasmus when he talks about his assembly-history. Do
you
really expect Annotations to perform better than hard-wired php-code?
Yes, and built-in support is WAY faster.
If I'm not mistaken, the current comment-parsing solutions are so slow that
the annotated classes and methods and attributes *NEED* the metadata to be
cached in separate PHP code in order to function, otherwise it would be
practically impossible to use them in production sites; conversely, if they
were supported natively caching would not be absolutely necessary. Is this
the case?, if so, I think it is a strong use case to be considered for the
RFC.
BTW, why is it rejected in the wiki now?. Is it completely completely
rejected?, or just postponed?... if it is just cataloged as declined for
now, perhaps it will be harder to retake for discussion later if it appears
as declined?.
--
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
--
--
// 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] annotations again
On Wed, May 11, 2011 at 4:57 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi duke, I moved it to rejected in pro of a new proposal. I briefly drafted it here: https://wiki.php.net/rfc/annotations-in-docblock There's a lot of things to be officially defined, but basic idea is there. I expect to have a chat with interested core devs to see what can be done in this subject and find some common sense. =) Ok, so the agreed direction now would be to have some initial support for annotations in comments to achieve syntax and data uniformity, and after its necessity/utility is obvious to everybody then we can move to native support?. Is this correct?. BTW, I love the idea of using JSON as value.
Re: [PHP-DEV] annotations again
@duke: Exactly. The idea is to expose this support through Reflection API @Marcelo: It is listed that this support would be necessary. On Wed, May 11, 2011 at 7:06 PM, dukeofgaming dukeofgam...@gmail.com wrote: On Wed, May 11, 2011 at 4:57 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi duke, I moved it to rejected in pro of a new proposal. I briefly drafted it here: https://wiki.php.net/rfc/annotations-in-docblock There's a lot of things to be officially defined, but basic idea is there. I expect to have a chat with interested core devs to see what can be done in this subject and find some common sense. =) Ok, so the agreed direction now would be to have some initial support for annotations in comments to achieve syntax and data uniformity, and after its necessity/utility is obvious to everybody then we can move to native support?. Is this correct?. BTW, I love the idea of using JSON as value. -- 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 11.05.2011 23:57, guilhermebla...@gmail.com wrote:
Hi duke,
I moved it to rejected in pro of a new proposal.
I briefly drafted it here: https://wiki.php.net/rfc/annotations-in-docblock
There's a lot of things to be officially defined, but basic idea is there.
I expect to have a chat with interested core devs to see what can be
done in this subject and find some common sense. =)
A few questions remarks, mostly to trigger discussion:
- What about nested annotations? @Foo [@Bar, @Baz]?
- Your JSON is invalid, it should be {repositoryClass:val} with
quotes. [1]
- simple strings should be handled without quotes if we want to support
current docblocks, like @author Guilherme Blanco should be enough.
Cheers
[1] And in this case single quotes are even invalid in json and I'm not
gonna complain ;)
--
Jordi Boggiano
@seldaek :: http://seld.be/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Le 10/05/2011 07:46, Lester Caine a écrit : The existing tools had been working well, but nowadays things are simply becoming a mess ... I agree. Why not fixing the several hundreds of bugs in PHP before just even thinking about adding new features ??? I much respect people using my programs thus for my projects I just forbid myself to release any new version which is not bug free as far as I know. It's getting harder and harder to make my php programs work because of memory leaks/corruptions :-( YMMV -- 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 10:46 PM, Lester Caine les...@lsces.co.uk wrote: *IS* it clear by now that the majority of users want this? For what it's worth, I still oppose Annotations. 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? I especially oppose the complexity of the current proposal. One of the reasons I prefer PHPDoc to the proposed Annotations is because they're a simple key=value syntax. I'm already doing my coding in PHP - why do I have to code in a new sub-language when all I want is a litte bit of meta-data? My main question is: Why do we need more than key=value? When you say that everyone supports annotations (if that is true), are you sure they actually want more than key=value? Discussion of this does not seem to appear in your Why do we need Class Metadata? section. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Tue, May 10, 2011 at 9:01 AM, Chad Fulton chadful...@gmail.com wrote: On Mon, May 9, 2011 at 10:46 PM, Lester Caine les...@lsces.co.uk wrote: *IS* it clear by now that the majority of users want this? For what it's worth, I still oppose Annotations. 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? I especially oppose the complexity of the current proposal. One of the reasons I prefer PHPDoc to the proposed Annotations is because they're a simple key=value syntax. that would be the same argument that we don't need objects because we have arrays, and if you only need something to store your structures, then both can be used for that. I'm already doing my coding in PHP - why do I have to code in a new sub-language when all I want is a litte bit of meta-data? nobody is forcing you to use annotations, it won't replace the docblocks. My main question is: Why do we need more than key=value? When you say that everyone supports annotations (if that is true), are you sure they actually want more than key=value? at least Doctrine, Symfony and FLOW3 does. Sebastian expressed that he is fine with the current Docblock support for PHPUnit. the FLOW3 used to use single key values in the past, but I'm not familiar with the current situation. for actual use-cases you can check http://blog.seric.at/2011/05/03/annotations-with-symfony2/ or http://www.doctrine-project.org/docs/orm/2.0/en/reference/annotations-reference.html#annref-column Discussion of this does not seem to appear in your Why do we need Class Metadata? section. I also think that it would be a good idea to link or describe annotations in general, because it seems that nobody bothers to read that up without joining the conversation... Tyrael
Re: [PHP-DEV] annotations again
Am 10.05.2011 09:44, schrieb Ferenc Kovacs:
On Tue, May 10, 2011 at 9:01 AM, Chad Fultonchadful...@gmail.com wrote:
On Mon, May 9, 2011 at 10:46 PM, Lester Caineles...@lsces.co.uk wrote:
*IS* it clear by now that the majority of users want this?
For what it's worth, I still oppose Annotations.
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?
I especially oppose the complexity of the current proposal. One of the
reasons I prefer PHPDoc to the proposed Annotations is because they're
a simple key=value syntax.
that would be the same argument that we don't need objects because we have
arrays, and if you only need something to store your structures, then both
can be used for that.
I'm already doing my coding in PHP - why do I have to code in a new
sub-language when all I want is a litte bit of meta-data?
nobody is forcing you to use annotations, it won't replace the docblocks.
My main question is: Why do we need more than key=value? When you say
that everyone supports annotations (if that is true), are you sure
they actually want more than key=value?
at least Doctrine, Symfony and FLOW3 does.
Sebastian expressed that he is fine with the current Docblock support for
PHPUnit.
the FLOW3 used to use single key values in the past, but I'm not familiar
with the current situation.
for actual use-cases you can check
http://blog.seric.at/2011/05/03/annotations-with-symfony2/
or
http://www.doctrine-project.org/docs/orm/2.0/en/reference/annotations-reference.html#annref-column
Discussion of this does not seem to appear in your Why do we need
Class Metadata? section.
I also think that it would be a good idea to link or describe annotations in
general, because it seems that nobody bothers to read that up without
joining the conversation...
Tyrael
From the user-end perspective, what I don't understand is this:
What is the goal of having Annotations embedded in PHP? To nail down a
common syntax? To provide an interface for meta-information on a class?
Why can't this be PHP code? Why should I have to learn a whole new kind
of syntax? We already have a common syntax (PHP interface) for this as
well as an interface (static Class-functions/Object-methods).
To explain what I mean, I'll use the example provided in the RFC. Could
anyone please explain the advantages of having passive annotations
over active PHP Code.
Entity(users)
class User
{
Column(integer)
Id
GeneratedValue(AUTO)
protected $id;
// ...
ManyToMany(Phonenumber)
protected $Phonenumbers;
}
*** Example ***
class User implements EntityAnnotation {
protected $id;
protected $Phonenumbers;
public function getEntityAnnotation(){
return new User_EntityAnnotation();
}
}
class User_EntityAnnotation {
public function getEntityName(){
return 'users';
}
public function getColumnInfo($property){
switch( $property ) {
case 'id': return array(
'column'='integer',
'isPrimary'=true,
'autoIncrement'=true
);
case 'Phonenumbers': return array(
'manytomany'='Phonenumber'
);
}
}
}
***
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Tue, May 10, 2011 at 10:02 AM, Lars Schultz lars.schu...@toolpark.com wrote: What is the goal of having Annotations embedded in PHP? To nail down a common syntax? To provide an interface for meta-information on a class? I think the main reasons are standardization of the syntax and performance of the parsing. At the moment everyone has to cache the stuff because hitting the tokenizer every time is quite expensive. Honestly if there was a way to parse them into the docblocks, I think it would be better because it would allow us to keep BC with older PHP versions, but since docblocks contain documentation as well, I think you can't really parse it all without creating a mess. Why can't this be PHP code? Why should I have to learn a whole new kind of syntax? We already have a common syntax (PHP interface) for this as well as an interface (static Class-functions/Object-methods). Annotations are not code, but more like metadata to tell the surrounding libraries how to work best with a piece of code. To explain what I mean, I'll use the example provided in the RFC. Could anyone please explain the advantages of having passive annotations over active PHP Code. I think your example shows very well why annotations are good, it's much more concise. Cheers -- Jordi Boggiano @seldaek :: http://seld.be/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 10.05.2011 10:10, schrieb Jordi Boggiano: I think the main reasons are standardization of the syntax and performance of the parsing. At the moment everyone has to cache the stuff because hitting the tokenizer every time is quite expensive. If implemented within PHP the existing opcode-caches could work wonders on this. Annotations are not code, but more like metadata to tell the surrounding libraries how to work best with a piece of code. What is code?;) What's the Problem with having meta-data within PHP-Code? I think your example shows very well why annotations are good, it's much more concise. But my example is much more verbose (which is good in my view), uses common syntax and is very flexible! It gives you the whole power of PHP instead of a semi-language (no offense). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 05/10/2011 01:10 AM, Jordi Boggiano wrote:
On Tue, May 10, 2011 at 10:02 AM, Lars Schultz
To explain what I mean, I'll use the example provided in the RFC. Could
anyone please explain the advantages of having passive annotations over
active PHP Code.
I think your example shows very well why annotations are good, it's
much more concise.
By concise, you mean shorter, easier to read?
I have a really hard time looking at:
Entity(users)
class User {
Column(integer)
Id
GeneratedValue(AUTO)
ManyToMany(Phonenumber)
protected $Phonenumbers;
}
as a PHP user and instantly understanding what this does. It looks
completely foreign from a PHP syntax point of view.
Whereas:
class User_EntityAnnotation {
public function getEntityName() {
return 'users';
}
public function getColumnInfo($property) {
switch($property) {
case 'id': return array(
'column'='integer',
'isPrimary'=true,
'autoIncrement'=true
);
case 'Phonenumbers': return array(
'manytomany'='Phonenumber'
);
}
}
}
is way more verbose, but I can instantly grok what is going on without
learning a new syntax, without waiting for my opcode cache to support
it, and without waiting for my editor to understand the new syntax.
Don't underestimate the difficulty in getting opcode cache support for
something like this. If you think the engine code is complex, try
digging into the opcode cache code. It will be much much harder to write
the opcode cache support than it was to write the engine code for it.
I also have a personal problem with code that needs to introspect on
every web request in order to run. But that is likely because I am old
and gray and used to stare sceptically at the assembly output of the
first C compilers to see if I could come up with an alternative that
would take fewer cycles.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Tue, May 10, 2011 at 5:45 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 05/10/2011 01:10 AM, Jordi Boggiano wrote:
On Tue, May 10, 2011 at 10:02 AM, Lars Schultz
To explain what I mean, I'll use the example provided in the RFC. Could
anyone please explain the advantages of having passive annotations over
active PHP Code.
I think your example shows very well why annotations are good, it's
much more concise.
By concise, you mean shorter, easier to read?
I have a really hard time looking at:
Entity(users)
class User {
Column(integer)
Id
GeneratedValue(AUTO)
ManyToMany(Phonenumber)
protected $Phonenumbers;
}
as a PHP user and instantly understanding what this does. It looks
completely foreign from a PHP syntax point of view.
Whereas:
class User_EntityAnnotation {
public function getEntityName() {
return 'users';
}
public function getColumnInfo($property) {
switch($property) {
case 'id': return array(
'column'='integer',
'isPrimary'=true,
'autoIncrement'=true
);
case 'Phonenumbers': return array(
'manytomany'='Phonenumber'
);
}
}
}
is way more verbose, but I can instantly grok what is going on without
learning a new syntax, without waiting for my opcode cache to support it,
and without waiting for my editor to understand the new syntax.
The editor argument is out of place
do you really think that the engine should we built around what IDE
supports?
Don't underestimate the difficulty in getting opcode cache support for
something like this. If you think the engine code is complex, try digging
into the opcode cache code. It will be much much harder to write the opcode
cache support than it was to write the engine code for it.
I also have a personal problem with code that needs to introspect on every
web request in order to run. But that is likely because I am old and gray
and used to stare sceptically at the assembly output of the first C
compilers to see if I could come up with an alternative that would take
fewer cycles.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Martin Scotta
On Tue, May 10, 2011 at 5:02 AM, Lars Schultz lars.schu...@toolpark.comwrote:
Am 10.05.2011 09:44, schrieb Ferenc Kovacs:
On Tue, May 10, 2011 at 9:01 AM, Chad Fultonchadful...@gmail.com
wrote:
On Mon, May 9, 2011 at 10:46 PM, Lester Caineles...@lsces.co.uk
wrote:
*IS* it clear by now that the majority of users want this?
For what it's worth, I still oppose Annotations.
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?
I especially oppose the complexity of the current proposal. One of the
reasons I prefer PHPDoc to the proposed Annotations is because they're
a simple key=value syntax.
that would be the same argument that we don't need objects because we have
arrays, and if you only need something to store your structures, then both
can be used for that.
I'm already doing my coding in PHP - why do I have to code in a new
sub-language when all I want is a litte bit of meta-data?
nobody is forcing you to use annotations, it won't replace the docblocks.
My main question is: Why do we need more than key=value? When you say
that everyone supports annotations (if that is true), are you sure
they actually want more than key=value?
at least Doctrine, Symfony and FLOW3 does.
Sebastian expressed that he is fine with the current Docblock support for
PHPUnit.
the FLOW3 used to use single key values in the past, but I'm not familiar
with the current situation.
for actual use-cases you can check
http://blog.seric.at/2011/05/03/annotations-with-symfony2/
or
http://www.doctrine-project.org/docs/orm/2.0/en/reference/annotations-reference.html#annref-column
Discussion of this does not seem to appear in your Why do we need
Class Metadata? section.
I also think that it would be a good idea to link or describe annotations
in
general, because it seems that nobody bothers to read that up without
joining the conversation...
Tyrael
From the user-end perspective, what I don't understand is this:
What is the goal of having Annotations embedded in PHP? To nail down a
common syntax? To provide an interface for meta-information on a class?
Why can't this be PHP code? Why should I have to learn a whole new kind of
syntax? We already have a common syntax (PHP interface) for this as well as
an interface (static Class-functions/Object-methods).
To explain what I mean, I'll use the example provided in the RFC. Could
anyone please explain the advantages of having passive annotations over
active PHP Code.
Annotated code integrates best with library/frameworks without the need to
extends or implements.
Without annotation you will need to extend some class or to implement some
interface. That means more code to write, more chances to shoot you foot.
With annotation your classes are unaware of the other components, which
implies:
* shorter, concise code = less bugs
* no extra dependencies = easy to test
class UserFoo extends LibraryFoo { }
class UserBar implements LibraryBar {
// even worst you will need to write some methods here
}
With annotations classes are free to live on you own herarchy
LibraryFoo class UserFoo extends UserFooBase { }
LibraryBar class UserBar { }
Entity(users)
class User
{
Column(integer)
Id
GeneratedValue(AUTO)
protected $id;
// ...
ManyToMany(Phonenumber)
protected $Phonenumbers;
}
*** Example ***
class User implements EntityAnnotation {
protected $id;
protected $Phonenumbers;
public function getEntityAnnotation(){
return new User_EntityAnnotation();
}
}
class User_EntityAnnotation {
public function getEntityName(){
return 'users';
}
public function getColumnInfo($property){
switch( $property ) {
case 'id': return array(
'column'='integer',
'isPrimary'=true,
'autoIncrement'=true
);
case 'Phonenumbers': return array(
'manytomany'='Phonenumber'
);
}
}
}
***
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 10.05.2011 14:28, schrieb Martin Scotta: The editor argument is out of place do you really think that the engine should we built around what IDE supports? At least the much quoted user-base would welcome syntax-support for this feature, wouldn't you agree? If support is already there, that's a big plus! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 10.05.2011 14:47, schrieb Martin Scotta:
Annotated code integrates best with library/frameworks without the need to
extends or implements.
Without annotation you will need to extend some class or to implement some
interface. That means more code to write, more chances to shoot you foot.
Umm. Is there any way with the Annotation-proposal to validate a class
to have all the necessary annotations to work with a certain framework?
Is there an annotation-Schema or DTD which I can apply against my
classes and validate them? Because that's what you get when using
interfaces. Which means less shooting in the foot.
As for writing less code...If there is any shared code, we now have
traits!;) hurray!
With annotation your classes are unaware of the other components, which
implies:
* shorter, concise code = less bugs
* no extra dependencies = easy to test
class UserFoo extends LibraryFoo { }
I can see that extending does not really work when using frameworks. But
when using interfaces and traits in conjunction, this is not necessary
anymore.
class UserBar implements LibraryBar {
// even worst you will need to write some methods here
}
I don't get what the problem with writing methods is. They are readable
by any PHP5 developer and you get all kind of support in writing them.
With annotations classes are free to live on you own herarchy
The same holds true for interfaces.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Rasmus Lerdorf wrote: I also have a personal problem with code that needs to introspect on every web request in order to run. But that is likely because I am old and gray and used to stare sceptically at the assembly output of the first C compilers to see if I could come up with an alternative that would take fewer cycles. AND fit it into the 16k of core store which was all an ICL1900 computer had to run on ... -- 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
Hi,
You all think that mapping something can always be abstracted into a
few lines like the one you presented.
Well, in certain cases your idea is valid. I'd then point you an
Entity mapping of Doctrine 2 with and without Annotations, so you can
imagine how much it can abstract:
With Doctrine Annotations: http://pastie.org/1885284
With my proposal: http://pastie.org/1885294
Without Annotations: http://pastie.org/1885252
Is that still simple?
Regarding usability, I thought that it is not it must be used by
10,000k people to be relevant.
I think the best thing that can prove that is goto. I didn't see a
lot of people requesting for it, but it was still included.
Let me ask you then: if it wasn't widely requested (considering your
argument that only massive requests should be relevant), why was it
included?
Regarding BC, IDEs, etc... Traits also includes new keywords and none
complained about IDE won't support immediately.
Should I consider then that your arguments that you are strongly
forcing to be valid on this subject should also be strong on traits?
If yes, why traits was included?
Regarding readability, traits and annotations follow a similar path.
Everything that annotations can do, with much more work PHP can do
too. The same applies to traits. So again I ask: if with PHP is
possible to do the same things that traits included, why was it
included?
I'm not putting traits support inclusion on risk. I'm a string +1 to it.
All I want is that you stop giving stupid arguments to be against the
patch instead of giving *real* relevant arguments.
Regards,
On Tue, May 10, 2011 at 11:12 AM, Lars Schultz
lars.schu...@toolpark.com wrote:
Am 10.05.2011 14:47, schrieb Martin Scotta:
Annotated code integrates best with library/frameworks without the need to
extends or implements.
Without annotation you will need to extend some class or to implement some
interface. That means more code to write, more chances to shoot you foot.
Umm. Is there any way with the Annotation-proposal to validate a class to
have all the necessary annotations to work with a certain framework? Is
there an annotation-Schema or DTD which I can apply against my classes and
validate them? Because that's what you get when using interfaces. Which
means less shooting in the foot.
As for writing less code...If there is any shared code, we now have
traits!;) hurray!
With annotation your classes are unaware of the other components, which
implies:
* shorter, concise code = less bugs
* no extra dependencies = easy to test
class UserFoo extends LibraryFoo { }
I can see that extending does not really work when using frameworks. But
when using interfaces and traits in conjunction, this is not necessary
anymore.
class UserBar implements LibraryBar {
// even worst you will need to write some methods here
}
I don't get what the problem with writing methods is. They are readable by
any PHP5 developer and you get all kind of support in writing them.
With annotations classes are free to live on you own herarchy
The same holds true for interfaces.
--
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] annotations again
guilhermebla...@gmail.com wrote: With Doctrine Annotations:http://pastie.org/1885284 With my proposal:http://pastie.org/1885294 Without Annotations:http://pastie.org/1885252 Is that still simple? But exactly what is wrong with the first one. It does not require getting a book out to work out what it means, and can easily be read by anybody who has been programming for a while. All I want is that you stop giving stupid arguments to be against the patch instead of giving*real* relevant arguments. Give practical examples of why we HAVE to change from what is currently working for many people already today? Why this is not simply being accepted is simply becuase we are already doing the same thing happily other ways -- 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
On Tue May 10 11:07 AM, guilhermebla...@gmail.com wrote: I'm not putting traits support inclusion on risk. I'm a string +1 to it. All I want is that you stop giving stupid arguments to be against the patch instead of giving *real* relevant arguments. Complexity: http://en.wikipedia.org/wiki/Enterprise_JavaBean Annotations serve as a good way for application containers to become relevant disguised as developer productivity. I know that whatever I say, you'll continue to support annotations religiously. Calling everyone else arguments stupid is far from a discussion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Lars Schultz wrote: Am 10.05.2011 14:28, schrieb Martin Scotta: The editor argument is out of place do you really think that the engine should we built around what IDE supports? At least the much quoted user-base would welcome syntax-support for this feature, wouldn't you agree? If support is already there, that's a big plus! And given the amount of time it is taking to get things like GIT and HG even vaguely functional in Eclipse and other IDE's who is expected to implement even the existing new features. Even the classname stuff still needs someone to support it in the IDE's :( As an interesting aside, HG is based on python2 and now that python3 is out questions are being asked about supporting that, but the core development team do not have the time since the two will not be backwards compatible. So it's not just PHP that is having difficulties bringing the user base along with these new developments. I'm only just getting a handle on python2 so that I can integrate my hg repo's with the rest of my PHP based code management -- 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
On 2011-05-10, Drak d...@zikula.org wrote: --0016e6db295ac0d29504a2e4229c Content-Type: text/plain; charset=UTF-8 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. Can you back this up, please? Just because developers are using annotations does not necessarily mean we need a new syntax. 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. I've gone on record as stating that annotations within docblocks are sufficient, and would rather see native support for parsing docblocks for annotations than introducing a new syntax. Others have stated the same. I'd like to see why a new syntax is considered necessary, and why native support for docblock annotations is not considered a reasonable path. -- 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
Hi Matthew, There's just one reason that it cannot be possible to do inside docblocks: - Code with and without comments should act the same. Also, no matter if it's inside docblocks or not, we'd still have a new syntax. No matter what you do. Even a key = value is a new syntax. But it seems that none notice what I've been trying to express with the patch: key = value is not enough. Doctrine and Symfony are 2 projects that requires more than key/value support, because annotations declaration requires state, something not possible with k/v. Anyway, someone asked me previously if other languages support complex annotations like I suggest, my answer is YES and I even included in RFC the links to .NET and Java implementation examples. Cheers, On Tue, May 10, 2011 at 12:57 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-05-10, Drak d...@zikula.org wrote: --0016e6db295ac0d29504a2e4229c Content-Type: text/plain; charset=UTF-8 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. Can you back this up, please? Just because developers are using annotations does not necessarily mean we need a new syntax. 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. I've gone on record as stating that annotations within docblocks are sufficient, and would rather see native support for parsing docblocks for annotations than introducing a new syntax. Others have stated the same. I'd like to see why a new syntax is considered necessary, and why native support for docblock annotations is not considered a reasonable path. -- 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 -- 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
Am 10.05.2011 17:57, schrieb Matthew Weier O'Phinney: Just because developers are using annotations does not necessarily mean we need a new syntax. Exactly the point I tried to make earlier -- just more to the point. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 2011-05-10, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: There's just one reason that it cannot be possible to do inside docblocks: - Code with and without comments should act the same. Why? Would you expect phpDocumentor to work without docblocks? No. Would you expect to know parameter types and return values without docblock annotations? No. In each of these cases, we know the capabilities based on the _comment_ - and we know that stripping out the comment and running specific tools on the code will simply not work. I'd expect the same of annotations via docblocks. There are no good reasons to strip out docblock comments at this point in PHP's history -- you don't gain speed, you don't improve parsing time; about the only reason I can see to do so would be to minimize file size for deployment -- and I'd argue even that is hard to justify. So, in sum, if your code depends on annotations support, you know that you cannot strip the comments. That's an easy rule to follow, and doesn't require a new PHP syntax. Also, no matter if it's inside docblocks or not, we'd still have a new syntax. No matter what you do. Even a key = value is a new syntax. But it seems that none notice what I've been trying to express with the patch: key = value is not enough. Doctrine and Symfony are 2 projects that requires more than key/value support, because annotations declaration requires state, something not possible with k/v. This is very easy to support in userland. I'd argue that a ReflectionDocComment class with the following signature would be sufficient: getShortDescription() getLongDescription() getAnnotations() hasAnnotation($name) getAnnotation($name) setAnnotationParser($callback) Annotations would be simply key/value pairs, and by default annotations would be recognized using the already popular standard of @annotationName, with the value being everything up to the next annotation or the end of the docblock. It would be up to the given annotation _CONSUMER_ to determine how to consume the value. With facilities such as json_decode(), you can already even mimic native PHP structures to a large degree. For cases where you want to utilize a different annotation format, the ability to set an alternative parser would allow you to write such a facility as an extension or in userland code, and its return value would be used to seed the annotations accessors. Anyway, someone asked me previously if other languages support complex annotations like I suggest, my answer is YES and I even included in RFC the links to .NET and Java implementation examples. I'm not one of those people. I already know that the support exists elsewhere. I'm simply not convinced we need anything outside of the ability to grab annotations from docblocks -- something that can be done in userland now, but which could be sped up with native extensions. On Tue, May 10, 2011 at 12:57 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-05-10, Drak d...@zikula.org wrote: --0016e6db295ac0d29504a2e4229c Content-Type: text/plain; charset=UTF-8 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. Can you back this up, please? Just because developers are using annotations does not necessarily mean we need a new syntax. 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. I've gone on record as stating that annotations within docblocks are sufficient, and would rather see native support for parsing docblocks for annotations than introducing a new syntax. Others have stated the same. I'd like to see why a new syntax is considered necessary, and why native support for docblock annotations is not considered a reasonable path. -- 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 05/10/2011 05:28 AM, Martin Scotta wrote: The editor argument is out of place do you really think that the engine should we built around what IDE supports? IDEs are part of the PHP ecosystem, just as much as frameworks, op code caches, documentation, bug reports, maintenance issues and even current technology trends. The benefits of a new feature must be calculated taking into account its impact on the whole ecosystem. 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] annotations again
On Tue, May 10, 2011 at 8:16 PM, Christopher Jones christopher.jo...@oracle.com wrote: On 05/10/2011 05:28 AM, Martin Scotta wrote: The editor argument is out of place do you really think that the engine should we built around what IDE supports? IDEs are part of the PHP ecosystem, just as much as frameworks, op code caches, documentation, bug reports, maintenance issues and even current technology trends. The benefits of a new feature must be calculated taking into account its impact on the whole ecosystem. creating an official EBNF would solve this problem, among others as well. http://marc.info/?l=php-internalsm=129387252319019 patches welcome ;) Tyrael
Re: [PHP-DEV] annotations again
Christopher Jones wrote: The editor argument is out of place do you really think that the engine should we built around what IDE supports? IDEs are part of the PHP ecosystem, just as much as frameworks, op code caches, documentation, bug reports, maintenance issues and even current technology trends. The benefits of a new feature must be calculated taking into account its impact on the whole ecosystem. And many of us do not recognise some of the 'complaints' simply because our own ecosystems have already solved the problem, but it's these 'new developments' that are threatening to destroy a perfectly stable system. -- 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
On Tue, May 10, 2011 at 8:22 PM, Lester Caine les...@lsces.co.uk wrote: Christopher Jones wrote: The editor argument is out of place do you really think that the engine should we built around what IDE supports? IDEs are part of the PHP ecosystem, just as much as frameworks, op code caches, documentation, bug reports, maintenance issues and even current technology trends. The benefits of a new feature must be calculated taking into account its impact on the whole ecosystem. And many of us do not recognise some of the 'complaints' simply because our own ecosystems have already solved the problem, but it's these 'new developments' that are threatening to destroy a perfectly stable system. sorry my FUD counter just overflowed with your last comment. Tyrael
Re: [PHP-DEV] annotations again
Hi all, Based on an extensive chat with Matthew, I think we reached some consensus. I'll write another RFC related to Annotations in docblocks, then we can chat until reach some standardization and availability. I'll keep the old one for history purposes. It seems that none from core php devs accepted it, so I'll move it to rejected. As I told you previously, all I wanted was some good feedback to give a north and that's what I had. As soon as I finish the new RFC, I'll open another thread here for fine-grain the support and discuss architecture. I'll keep Stas comments in mind when creating it, so it would help in discussions. It seems we still have 2 weeks to discuss the new idea and less than 2 months to get it ready if everyone agreed. Regards, On Tue, May 10, 2011 at 3:28 PM, Ferenc Kovacs i...@tyrael.hu wrote: On Tue, May 10, 2011 at 8:22 PM, Lester Caine les...@lsces.co.uk wrote: Christopher Jones wrote: The editor argument is out of place do you really think that the engine should we built around what IDE supports? IDEs are part of the PHP ecosystem, just as much as frameworks, op code caches, documentation, bug reports, maintenance issues and even current technology trends. The benefits of a new feature must be calculated taking into account its impact on the whole ecosystem. And many of us do not recognise some of the 'complaints' simply because our own ecosystems have already solved the problem, but it's these 'new developments' that are threatening to destroy a perfectly stable system. sorry my FUD counter just overflowed with your last comment. 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 10 May 2011 21:42, Matthew Weier O'Phinney weierophin...@php.net wrote: 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. Can you back this up, please? Just because developers are using annotations does not necessarily mean we need a new syntax. Sure - I just revisited my browser history today. I turned up at least dozen annotation driver implementations (including 3 separate PHP C implementations!) just with a casual google search. Google Searches --- Lots of pages specifically about PHP annotations (9,470): http://www.google.com/search?hl=enq=php+annotations; PHP Annotations + patch (5,000) http://www.google.com/search?hl=enq=php+annotations+patch PHP annotations (1.8 million) http://www.google.com/search?q=php+annotations - you can see lots and lots of chatter about PHP annotations. C patches for PHP - http://labs.adoy.net/php-annotations.php (source: https://github.com/adoy/PHP-Annotations) http://code.google.com/p/addendum/ https://github.com/marcelog/AnoForPHP Guilherme Blanco's of course PHP based annotation drivers --- https://github.com/schmittjoh/annotations https://github.com/jubianchi/PHPAnnotations https://github.com/oes/pia http://sourceforge.net/projects/phpannotations/ https://github.com/veritech/Annotations (for CakePHP) https://github.com/domain51/Domain51_Tool_Annotation https://github.com/doomspork/sleepy PHPUnit :-P Doctrine and so on... ... and these are just projects which have written annotation drivers found during a quick search. There is clearly a lot of interest from PHP userland in annotations, evidenced that annotations have been being used for years already, most notably by PHPUnit from so long ago. As frameworks adopt annotations the use of annotations will escalate more and more and it's already happening since many people use PHP frameworks: people using the frameworks inevitably use the technology in the framework. Also logically, people would not be writing drivers if there was not a demand for it. I feel like I am stating the obvious :) If PHP accept the patch (in it's current or a modified form) it should be feature complete. There is no point neutering a perfectly good feature at it's inception. Whether it's in the docblock, or as Guilherme's designed in the code, annotations should accept more than key=value. Drak PS - sorry to say this but from the other thread, all this talk of ecosystems is quite strange and full of FUD. The PHP eco-system depends on PHP and exists only because of PHP, not the other way round. If PHP adds a new syntax or new functions, the IDEs have to support it - it's only logical or they will lose users to another product which does support PHP properly and in a timely manner. IDE vendors provide a solution for people who need a PHP IDE so it only goes to reason surely? Given their scale and userbase I cant see Beans and Eclipse PDT ignoring new syntax any time soon nor any of the commercial IDEs like Zend Studio or phpStorm. If they managed with namespace support I don't see why this would be any different. I feel like I'm stating the obvious. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 05/10/2011 12:35 PM, guilhermebla...@gmail.com wrote: Hi all, Based on an extensive chat with Matthew, I think we reached some consensus. I'll write another RFC related to Annotations in docblocks, then we can chat until reach some standardization and availability. I'll keep the old one for history purposes. It seems that none from core php devs accepted it, so I'll move it to rejected. As I told you previously, all I wanted was some good feedback to give a north and that's what I had. As soon as I finish the new RFC, I'll open another thread here for fine-grain the support and discuss architecture. I'll keep Stas comments in mind when creating it, so it would help in discussions. It seems we still have 2 weeks to discuss the new idea and less than 2 months to get it ready if everyone agreed. One suggestion. Be very careful about anything that requires changes in the opcode caches out there. Such changes will be very slow in coming, if at all. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 11 May 2011 01:30, Rasmus Lerdorf ras...@lerdorf.com wrote: One suggestion. Be very careful about anything that requires changes in the opcode caches out there. Such changes will be very slow in coming, if at all. It's unrelated to this thread but, what is the status of merging APC into the PHP core? I remember this being discussed at some point. Drak -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 05/10/2011 12:49 PM, Drak wrote: On 11 May 2011 01:30, Rasmus Lerdorfras...@lerdorf.com wrote: One suggestion. Be very careful about anything that requires changes in the opcode caches out there. Such changes will be very slow in coming, if at all. It's unrelated to this thread but, what is the status of merging APC into the PHP core? I remember this being discussed at some point. Next major release. We don't have enough manpower to do it for 5.4. Right now it is only Gopal that is working on that code. Once we merge it is going to take people quite a while to get their heads around it. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Tue, May 10, 2011 at 12:35 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi all, Based on an extensive chat with Matthew, I think we reached some consensus. I'll write another RFC related to Annotations in docblocks, then we can chat until reach some standardization and availability. I'll keep the old one for history purposes. It seems that none from core php devs accepted it, so I'll move it to rejected. As I told you previously, all I wanted was some good feedback to give a north and that's what I had. As soon as I finish the new RFC, I'll open another thread here for fine-grain the support and discuss architecture. I'll keep Stas comments in mind when creating it, so it would help in discussions. It seems we still have 2 weeks to discuss the new idea and less than 2 months to get it ready if everyone agreed. Please first take a look at the current RFC regarding parsing docblocks: https://wiki.php.net/rfc/docblockparser . Even if you want to put up a competing RFC, at least you can use it as a point of reference. Chad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On 05/10/2011 12:37 PM, Drak wrote: PS - sorry to say this but from the other thread, all this talk of ecosystems is quite strange and full of FUD. The PHP eco-system depends on PHP and exists only because of PHP, not the other way round. If PHP adds a new syntax or new functions, the IDEs have to support it - it's only logical or they will lose users to another product which does support PHP properly and in a timely manner. IDE vendors provide a solution for people who need a PHP IDE so it only goes to reason surely? Given their scale and userbase I cant see Beans and Eclipse PDT ignoring new syntax any time soon nor any of the commercial IDEs like Zend Studio or phpStorm. If they managed with namespace support I don't see why this would be any different. I feel like I'm stating the obvious. From a very narrow technical point of view it may appear obvious but it would lead to a fun paradox that a language feature for the community could get designed without thinking about all the users uses. -- 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] annotations again
Ferenc Kovacs wrote: sorry my FUD counter just overflowed with your last comment. Sorry you feel that way, but obviously there are more people with my view that we simply do not agree on IF annotation should be implemented. I'm a lot more comfortable with something that works WITH what we already have rather than going off on yet another tangent. Tidying existing docblock content to an updated format makes a lot more sense then having to do a wholesale re-write many thousands of files. Adding another copy of much of the same data in a complete different format is equally insane? PDO is another case in point - that is still not accepted and fully functional as a replacement for the genric drivers ... ADOdb still provides a valid abstraction layer, and if you must use PDO then it just loads that instead of the generic one ... and it runs just as fast on either. PDO is functional, but needs more work, however there are few people that find the need for improving it? -- 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
Am 10.05.2011 17:07, schrieb guilhermebla...@gmail.com: Is that still simple? You bloated the php example unnecessarily. This contains the same information as your Annotations example, which to me, is very similar. http://pastie.org/1886774 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Not trying to be harsh, but I'm not bloating my PHP example. That's the actual way Doctrine supports Metadata information. I can explain why. Conceptually, an architectural design of an entity should not know anything about its persistence information. By that means, we cannot for example implement an interface (which seems you have forgotten to add) or an abstract class for getAnnotations() method. If you enforce people to implement an abstract class or even an interface, you bring 2 problems: - Entities with knowledge about its persistence information - Resources being wasted - You rely on an instance to grab information. Or you use a slow approach of having a static method The second argument is valid because in a request you're able to deal with an average number of methods. Each method is a pointer of 4 bytes. By having an irrelevant method on entity, you consume (on a page with 500 entities), 2000 bytes of unnecessary resources. The third argument is exactly what we had on Doctrine 1. We relied on a ghost entity for metadata retrieval. This brings a whole new level of issues to deal with. Making it static, slow down a lot the overall ClassMetadata retrieval information. Also, there are much more things than you can actually think of related to this. The code is not bloated. Since you don't have a pre-processor for class metadatas, you have to build all definitions manually. This is why you have to set inheritance type, for example. $metadata-setInheritanceType(ClassMetadataInfo::INHERITANCE_TYPE_NONE); FYI, Doctrine took an year of planning an another year of careful implementation of each feature. This means to you that every single feature was carefully planned, optimized and implemented with performance, good OO design and extensibility. =) Cheers, On Tue, May 10, 2011 at 7:03 PM, Lars Schultz lars.schu...@toolpark.com wrote: Am 10.05.2011 17:07, schrieb guilhermebla...@gmail.com: Is that still simple? You bloated the php example unnecessarily. This contains the same information as your Annotations example, which to me, is very similar. http://pastie.org/1886774 -- 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] annotations again
On Tue, 2011-05-10 at 20:21 +0200, Ferenc Kovacs wrote: creating an official EBNF would solve this problem, among others as well. http://marc.info/?l=php-internalsm=129387252319019 patches welcome ;) A formal syntax description might help with highligting, not with all assisting features an IDE provides (good and useful autocomplete, having some visualisation of the code structure (class tree incl. annotation) and all these) The main point in regards to IDEs and such thing imo is that it shows how long it takes for the eco system to pick a change up. The result is that it takes ages till a new standard can be relied upon. This is worse for a new syntax as there is no way to have code compatible with 5.4 and 5.3 then. There focussing around the existing way (doc block, more efficient doc block parsing, ...) helps. Then again proper annotations might solve tomorrows problem. johannes, who does not argue about annotations themselves -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
guilhermebla...@gmail.com wrote: So, please stop saying no to every feature request that comes in and start to discuss the actual impact of each feature. I think that MY only problem with you 'adding annotations because it is missing' is simply that I've already been doing it for years - just not calling it 'annotations' ... its 'documentation' and always has been ... MANY things that have been proposed are pushed as 'missing', when those of us with a different ecosystem have solved the problem in other ways long ago and do not see that. The real problem at present is that the whole ecosystem is now so disjointed that PHP5.2 is the last version that is still fairly fully supported, but people are pushing for 5.4 before 5.3 has been properly put to bed. We need to finish of what is already added fully before pushing more new stuff in? That INCLUDES in the ecosystem! And we still have the hole that is unicode ... -- 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
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] 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] 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] 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] 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] 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] 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
