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] 5.4 again
On 05/10/2011 01:04 PM, Stefan Marr wrote: The whole thing required a lot of, what I would characterize as, hand-holding. Internals is not the most open community and needs not only good arguments, but persistence. And, well, it also seem to require to get in touch with the right people... And now the whole discussion about 5.4 goes again in a direction where it will probably be stalled in the end. I am not to optimistic about an actual release date within 2011. Don't lose your head on it. If you look at the output buffering code contained in trunk (which is to become 5.4), you may discover that it has been written exactly 5 years ago. Cheers, Mike -- 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 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
[PHP-DEV] SVN Account Request: camro
Maintaining and improving the PHP website -- 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] 5.4 again
On Wed, May 11, 2011 at 2:52 AM, Michael Wallner m...@php.net wrote: On 05/10/2011 01:04 PM, Stefan Marr wrote: The whole thing required a lot of, what I would characterize as, hand-holding. Internals is not the most open community and needs not only good arguments, but persistence. And, well, it also seem to require to get in touch with the right people... And now the whole discussion about 5.4 goes again in a direction where it will probably be stalled in the end. I am not to optimistic about an actual release date within 2011. Don't lose your head on it. If you look at the output buffering code contained in trunk (which is to become 5.4), you may discover that it has been written exactly 5 years ago. *gasps*
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] making system calls from a php extension
On 11/05/11 2:33 PM, Rasmus Lerdorf wrote: On May 10, 2011, at 21:01, Gabriel Sosasosagabr...@gmail.com wrote: I'm basically using lynx to convert some html into plain text basically replicating the following command: *lynx -pseudo_inlines=off -hiddenlinks=merge -reload -cache=0 -notitle -force_html -dump -nocolor -stdin* I've been looking but I didn't find any other library capable to do the same with almost the same quality. You may be right that it does it better than other mechanisms and it may be the way to go. But it sounds like you need it to be faster. You are still not going to gain much simply by calling lynx from C. The only way to speed this up is to not have to fork and exec a new process on every request. One way to do that would be to figure out how to talk to an already running instance of lynx. Then write a little Gearman wrapper for them and launch a bunch of Gearman workers. Another benefit of this approach is that you will be able call lynx asynchronously. Rasmus is spot on, but another thought is that if your content is often the same, caching it somehow (either with PHP code or with a PHP extension--I would just try PHP code for starters) could yield large speed-ups, too. Ben. -- 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] 5.4 again
Well, maybe it's time to make some decisions and start to spin the wheels? I's quite obvious that annotations are out for next release until they are a docbook/phpDoc style. Personally I do not understand the concept fully, but my vote will definetly go to the docbook/phpdoc variant. Adding a whole new syntax is just crazy. PHP is a scripting language, not the Java/C# and alike, it should stay simple. Period. I hope KISS still is a PHP principle? Sometimes i'm sorry I don't like to do C - it just scared me away in college. Because people here sometimes just do strange things witch tend me to beleve that they do not know the PHP - they know C and try to add things they know from other languages so they don't have to learn the PHP way of doing things. Till the typehint threads and annotation threads i liked the core developer responces and the way php has been heading. Can we keep that and stop discussing things that are 100% alien to php like strict type hinting? in php? are you insane? same with annotations. wana do them? do them simple. docbook/phpdoc annotations allready exist - work out a standart and implement - clean, simple, fast and all ready exists within community. It's a no brainer. Same with features that have been worked on and forgotten. Revisit, finish and people will like it - there are thing people ask and thouse aren't annotations right now. Community wants typehints and a bunch of stuff from that RFC page. I hope a spark of reason and sanity will ignight and the procces will start in a few days, or PHP will be seriously screwed in a few years and i will have to make python my primary web development language and i don't wana do that. Arvids.
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] 5.4 again
-Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Sunday, May 08, 2011 4:41 PM To: PHP Internals Subject: [PHP-DEV] 5.4 again Hi! I would like to propose the following process (of course, dates can be moved around, etc. - I consider phase lengths be more important that actual dates, but any of them can be shifted if reason arises) for 5.4: - starting now - nominate features for 5.4 (see https://wiki.php.net/todo/php54), discussion on them - May 18 - start voting and debating on features that have no clear consensus support immediately. On the end of May is also phptek, so we could have some discussion there about it if needed. - June 15 (a bit more than a month) - alpha, branching of 5_4, open only for bugfixes and features in TODO list that are approved and can be done by beta time. - July 20 - beta, bugfixes only (if we add a lot of features, we may want to insert another 1-month alpha period, so far it doesn't look like it but may change) - Aug 24 - RC1, then an RC every 2 weeks until stable - Release - somewhere in October or November, depending on the RCs. I think we need to start moving. Not much is happening in 5.4 now as far as I can see, and we have a good feature set that is long due to be released. Stas, in the past we had alphas. Is there any reason why we wouldn't roll one out asap? (revert the typehints stuff and go). I think we (almost) all agree that we need to start pushing PHP 5.4 with all the goodness that has been developed to-date. Additional features can wait for the next version. Any exceptions that are low risk can be evaluated (an additional minor API, some additional enhancements) but let's get the good work that has been done to-date out there vs. allowing feature creep and pushing the timeline for another 1-2 years. I think we should start pushing out alpha in parallel to these discussions. Most of them sound like major features which would not make PHP 5.4 as any major feature requires plenty of time to mature (and needless to say some of them won't even be accepted). There is plenty to get excited about in PHP 5.4! Andi (sending in plaintext. Hope this gets rid of the funky newlines from prior emails) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
I think an idea of an alpha right away is a good one. I feel we definitely have enough stuff in HEAD branch right now for 5.4 +/- few minor changes. It should also be a good boost to getting people on track that 5.4 is a go. On Wed, May 11, 2011 at 2:03 PM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Sunday, May 08, 2011 4:41 PM To: PHP Internals Subject: [PHP-DEV] 5.4 again Hi! I would like to propose the following process (of course, dates can be moved around, etc. - I consider phase lengths be more important that actual dates, but any of them can be shifted if reason arises) for 5.4: - starting now - nominate features for 5.4 (see https://wiki.php.net/todo/php54), discussion on them - May 18 - start voting and debating on features that have no clear consensus support immediately. On the end of May is also phptek, so we could have some discussion there about it if needed. - June 15 (a bit more than a month) - alpha, branching of 5_4, open only for bugfixes and features in TODO list that are approved and can be done by beta time. - July 20 - beta, bugfixes only (if we add a lot of features, we may want to insert another 1-month alpha period, so far it doesn't look like it but may change) - Aug 24 - RC1, then an RC every 2 weeks until stable - Release - somewhere in October or November, depending on the RCs. I think we need to start moving. Not much is happening in 5.4 now as far as I can see, and we have a good feature set that is long due to be released. Stas, in the past we had alphas. Is there any reason why we wouldn't roll one out asap? (revert the typehints stuff and go). I think we (almost) all agree that we need to start pushing PHP 5.4 with all the goodness that has been developed to-date. Additional features can wait for the next version. Any exceptions that are low risk can be evaluated (an additional minor API, some additional enhancements) but let's get the good work that has been done to-date out there vs. allowing feature creep and pushing the timeline for another 1-2 years. I think we should start pushing out alpha in parallel to these discussions. Most of them sound like major features which would not make PHP 5.4 as any major feature requires plenty of time to mature (and needless to say some of them won't even be accepted). There is plenty to get excited about in PHP 5.4! Andi (sending in plaintext. Hope this gets rid of the funky newlines from prior emails) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4 again
On Wed, 2011-05-11 at 18:03 +, Andi Gutmans wrote: Stas, in the past we had alphas. Is there any reason why we wouldn't roll one out asap? (revert the typehints stuff and go). +1 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On May 11, 2011, at 12:20 PM, Johannes Schlüter wrote: On Wed, 2011-05-11 at 18:03 +, Andi Gutmans wrote: Stas, in the past we had alphas. Is there any reason why we wouldn't roll one out asap? (revert the typehints stuff and go). +1 Waiting a month or two longer is worth it, especially considering the 5.4 momentum feels real this time around. We're creating a real TODO, and have a real tentative timeline, so forcing a premature alpha at this point (thus closing off feature/api discussion) is a bad idea. A big -1 here. I mean, we may as well get it right since we've waited so long already. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Martin Scotta On Wed, May 11, 2011 at 2:18 PM, Arvids Godjuks arvids.godj...@gmail.comwrote: Well, maybe it's time to make some decisions and start to spin the wheels? I's quite obvious that annotations are out for next release until they are a docbook/phpDoc style. Personally I do not understand the concept fully, but my vote will definetly go to the docbook/phpdoc variant. Adding a whole new syntax is just crazy. PHP is a scripting language, not the Java/C# and alike, it should stay simple. Period. I hope KISS still is a PHP principle? Sometimes i'm sorry I don't like to do C - it just scared me away in college. Because people here sometimes just do strange things witch tend me to beleve that they do not know the PHP - they know C and try to add things they know from other languages so they don't have to learn the PHP way of doing things. Till the typehint threads and annotation threads i liked the core developer responces and the way php has been heading. Can we keep that and stop discussing things that are 100% alien to php like strict type hinting? in php? are you insane? same with annotations. wana do them? do them simple. docbook/phpdoc annotations allready exist - work out a standart and implement - clean, simple, fast and all ready exists within community. It's a no brainer. Clean? Simple? fast? are you talking about PHP? :) Now seriously I feel that trying to put things from other languages is wrong, but that don't prevent us from learning from what other had learn before. For me, annotations belongs to Object Oriented programming, no matter where they came from. Probably this list is too C to speak about OO ? Same with features that have been worked on and forgotten. Revisit, finish and people will like it - there are thing people ask and thouse aren't annotations right now. Community wants typehints and a bunch of stuff from that RFC page. I hope a spark of reason and sanity will ignight and the procces will start in a few days, or PHP will be seriously screwed in a few years and i will have to make python my primary web development language and i don't wana do that. Arvids.
Re: [PHP-DEV] 5.4 again
Hi! Stas, in the past we had alphas. Is there any reason why we wouldn't roll one out asap? (revert the typehints stuff and go). OK, I can do the stuff (typehints, branch, tag) on the weekend. I don't know how to roll the packages do the mails though, so if somebody could volunteer there it'd be great :) Some of the proposed changes though are not BC-safe, so we should warn people that this alpha is not the fixed API yet. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi! Waiting a month or two longer is worth it, especially considering the 5.4 momentum feels real this time around. We're creating a real TODO, and have a real tentative timeline, so forcing a premature alpha at this point (thus closing off feature/api discussion) is a bad idea. A big -1 here. I mean, we may as well get it right since we've waited so long already. I don't think it's closing feature discussion. We can have another alpha after the discussion, or more than one. I can see the value of having _something_ right now to signify we mean it this time, but that something would definitely not be anything near final and we can take features in after the discussion is done. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On Wed, 2011-05-11 at 11:43 -0700, Stas Malyshev wrote: Hi! Stas, in the past we had alphas. Is there any reason why we wouldn't roll one out asap? (revert the typehints stuff and go). OK, I can do the stuff (typehints, branch, tag) on the weekend. I don't know how to roll the packages do the mails though, so if somebody could volunteer there it'd be great :) Most parts (all?) is documented in README.RELEASE_PROCESS I can assist. 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 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] 5.4 again
Hi! Most parts (all?) is documented in README.RELEASE_PROCESS I can assist. Thanks! Interestingly enough, this file still refers to CVS in trunk. I guess somebody familiar with up-to-date process has to update it :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi! Most parts (all?) is documented in README.RELEASE_PROCESS I can assist. Thanks! Interestingly enough, this file still refers to CVS in trunk. I guess somebody familiar with up-to-date process has to update 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
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] 5.4 again
On 05/11/2011 08:20 PM, Johannes Schlüter wrote: +1 +1 -- 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] 5.4 again
On May 11, 2011, at 12:50 PM, Stas Malyshev wrote: Hi! Waiting a month or two longer is worth it, especially considering the 5.4 momentum feels real this time around. We're creating a real TODO, and have a real tentative timeline, so forcing a premature alpha at this point (thus closing off feature/api discussion) is a bad idea. A big -1 here. I mean, we may as well get it right since we've waited so long already. I don't think it's closing feature discussion. We can have another alpha after the discussion, or more than one. I can see the value of having _something_ right now to signify we mean it this time, but that something would definitely not be anything near final and we can take features in after the discussion is done. The alpha release proposal by Andi contains the text: I think we (almost) all agree that we need to start pushing PHP 5.4 with all the goodness that has been developed to-date. Additional features can wait for the next version. So, that's the concern there. But if the alpha is simply a trick to convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do it. ;) Regards, Philip -- 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] 5.4 again
On 05/11/2011 02:10 PM, Philip Olson wrote: So, that's the concern there. But if the alpha is simply a trick to convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do it. ;) There are still quite a few test failures in trunk. Some of them are also in the 5_3 branch. In some cases the tests are simply bad. In a few the test case contains binary data that got mangled in the move to Subversion. It would be nice if just 1 in 10 people reading the list here would grab both trunk and 5_3 and run make test in each tree and then fix at least 1 test each. We would have no test failures by the end of the day other than a few tricky ones. If an alpha release will encourage this, great. If we could get people to just do it on their own without the alpha, even better. And yes, I know the tests take forever to run. Get yourself a fast machine with an SSD, and remember you can run partial tests using: make test TESTS=ext/hash for example to just run the tests for the hash extension. Also, when a test fails, cd into the ext/hash/tests directory and you will see .out, .exp, .diff and .php files for the failed test. That is, the output, the expected output, the diff between them and the php script itself extracted from the .phpt file containing the failed test case. And if you can't figure out how to fix a test, post the details here. I'd love to point some of the obvious talents and energy of this list towards the code. If you don't have an svn account for committing your fixed test, go to http://www.php.net/svn-php.php and fill in the little form at the bottom there and put in the test that you fixed and a 1-liner about how you fixed it and I will set you up with an account right away. Info on how to check out the code from svn is here: https://wiki.php.net/vcs/svnfaq -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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] 5.4 again
Hi: On 11 May 2011, at 23:10, Philip Olson wrote: On May 11, 2011, at 12:50 PM, Stas Malyshev wrote: The alpha release proposal by Andi contains the text: I think we (almost) all agree that we need to start pushing PHP 5.4 with all the goodness that has been developed to-date. Additional features can wait for the next version. So, that's the concern there. But if the alpha is simply a trick to convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do it. ;) +1 that would definitely demonstrate the ability to get moving again. An important sign to the larger community. However, the stability/instability of the feature set should be clearly defined. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On May 11, 2011, at 3:56 PM, Rasmus Lerdorf wrote: On 05/11/2011 02:10 PM, Philip Olson wrote: So, that's the concern there. But if the alpha is simply a trick to convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do it. ;) There are still quite a few test failures in trunk. Some of them are also in the 5_3 branch. In some cases the tests are simply bad. In a few the test case contains binary data that got mangled in the move to Subversion. It would be nice if just 1 in 10 people reading the list here would grab both trunk and 5_3 and run make test in each tree and then fix at least 1 test each. We would have no test failures by the end of the day other than a few tricky ones. If an alpha release will encourage this, great. If we could get people to just do it on their own without the alpha, even better. And yes, I know the tests take forever to run. Get yourself a fast machine with an SSD, and remember you can run partial tests using: make test TESTS=ext/hash for example to just run the tests for the hash extension. Also, when a test fails, cd into the ext/hash/tests directory and you will see .out, .exp, .diff and .php files for the failed test. That is, the output, the expected output, the diff between them and the php script itself extracted from the .phpt file containing the failed test case. And if you can't figure out how to fix a test, post the details here. I'd love to point some of the obvious talents and energy of this list towards the code. If you don't have an svn account for committing your fixed test, go to http://www.php.net/svn-php.php and fill in the little form at the bottom there and put in the test that you fixed and a 1-liner about how you fixed it and I will set you up with an account right away. Info on how to check out the code from svn is here: https://wiki.php.net/vcs/svnfaq This is a great challenge. Long ago I decided that failed tests are expected in PHP, because out of the ~100 or so times I've run it these past n years, it has always (afair) failed. Changing this fact by having it pass would change peoples (at least my) perception that running 'make test' is a waste of time, as is (was) looking into why they failed. For example, just now trunk gives me 55 failed tests and 17 expected fails with a vanilla build. We once had a matrix showing test results per setup (OS, phpversion, per configure switches) but it was someones pet project and the code has long since been lost (he looked years ago). Maybe such a beast would be useful. Also, how about we change[1] it so php.qa.reports[2] stops receiving 5_2 results, and always receives snapshot results? For example, snapshot test results (5_3 and trunk) are configured to _not_ go there today. Regards, Philip [1] http://svn.php.net/viewvc/web/qa/trunk/include/release-qa.php [2] http://news.php.net/php.qa.reports -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
Hi! We once had a matrix showing test results per setup (OS, phpversion, per configure switches) but it was someones pet project and the code has long since been lost (he looked years ago). Maybe such a beast would be useful. We can do a table saying which tests fails where in the wiki right now... Also, how about we change[1] it so php.qa.reports[2] stops receiving 5_2 results, and always receives snapshot results? For example, snapshot test results (5_3 and trunk) are configured to _not_ go there today. I think it's an excellent idea. 5.2 is not going to be fixed anyway, we need 5.3 and trunk much more. -- 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 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
