5.4 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

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

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

guilhermeblanco@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 | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

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.

Drak wrote:

Matthew Weier O'Phinney wrote:
Thank you Matthew. That was the part of the 'problem' I was not getting
across very well. The bulk of my existing code base has this documentation
already, and phpeclipse simply picks it up and runs with it ...
including type hinting ...
If PHP releases new syntax of course the IDE vendors will release
support pronto for it.

Which world do you live in? We have to find the time to DO all this extra work!
Or are you only using commercial product?

--
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

--bcaec51a7af89cba6304a2f01d01
Content-Type: text/plain; charset=UTF-8

May-10-11 11:57 AM Matthew Weier O'Phinney wrote:

A native docblock annotation parser would much better suit our
purposes.

+1, FWIW.

extending the Reflection::getDocComment to support retrieving the docblock
comment as an array of key => value pairs wouldn't be too hard to implement.
I find it funny that you, Sebastian and others who are supporting docblocks
over annotations didn't found the time to do it, but you always bring this
up.

We have in ZF -- Zend_Reflection extends the Reflection API to provide
this sort of feature (though admittedly the annotation, or "tag" support
as we called it, could use a little more rigor in matching). I
personally am not comfortable enough in my C skills to attempt it in the
Zend Engine.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

I find it funny that you, Sebastian and others who are supporting docblocks
over annotations didn't found the time to do it, but you always bring this
up.

http://pecl.php.net/package/docblock exists. I never used it, but either
it is completely unknown or doesn't bring benefits over a userspace
implementation (typical trade-offs: A C implementation is harder to
maintain for developers and harder to install for users, while the PHP
implementation is slower)

johannes

Hi!

Well, there is the impact, but seriously, do that many people will use
it in production? I certainly will not, but on the DEV and on my local
development machine it will be enabled period.

Everybody would be using that in production. Production is where the
danger is, nobody would break into developer machine since nobody can
access it except for developers!

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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.

Regards,

so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and on
irc, where discussions and decisions happen, and they usually have
different
priorities and expectations about the PHP language than the core devs.
to make things worse, they cannot write patches for the core, and the core
devs rarely work on something which they don't particularly need or like.

and I think that the only option where we can change that, is that us, the
php userland devs has to be more active on the mailing lists, irc, bug
tracking, writing RFCs etc.

Why not open a Google Groups list?, having every message recorded publicly
and being easy to join-in I'd bet that the situation would change. I've seen
it work really well for other open source projects, such as Joomla and
Symfony.

Regards,

David Vega

--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil

On Tue, May 10, 2011 at 9:28 PM, dukeofgaming dukeofgaming@gmail.comwrote:

so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and on
irc, where discussions and decisions happen, and they usually have
different
priorities and expectations about the PHP language than the core devs.
to make things worse, they cannot write patches for the core, and the core
devs rarely work on something which they don't particularly need or like.

and I think that the only option where we can change that, is that us, the
php userland devs has to be more active on the mailing lists, irc, bug
tracking, writing RFCs etc.

Why not open a Google Groups list?, having every message recorded publicly
and being easy to join-in I'd bet that the situation would change. I've seen
it work really well for other open source projects, such as Joomla and
Symfony.

you can already do that through http://marc.info/?l=php-internals or the
newsgroup, see http://php.net/mailing-lists.php
albeit google groups is better imho

Tyrael