Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: 5.4 again)

14 years ago by Richard Quadling — view source

unread

On 9 May 2011 15:44, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:

It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.

But surely it is a motivational factor to learn C, and have a go at
implementing the feature yourself! That's what Open Source is all
about. If you don't like the feature, or it is missing one, DO
something about it. Saying that the developers are "not interested"
isn't really doing anything.

You really can't expect volunteers to simply down tools from family,
life, paid work to jump through hoops, attempting to make sense of
every user's request. No matter how loud they shout.

Now. If you had a pot (and a big pot) of money, then maybe you could
sponsor some developers for your pet peeve. I'll take your money.

As a volunteer to the PHP project (mainly making an arse of myself in
as many places as possible) and a PHP user, I am deeply indebted to
all the work undertaken by the core devs. I get paid because of them.

Please treat the devs nicely is all I'm really saying.

Richard.

Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi Richard,

Again what I commented on other thread and again you barely see what I
mentioned, the feature is ALREADY written in C and compatible with
latest PHP trunk.
I'm not bitching against do and don't dos... I'm bitching about
ignored feature that are not even discussed.

I agree with you, it's an Open Source project and any help from any
front is valuable.
But as I pointed out on other thread, only developers with php-src
karma had features evaluated.
If you think I'm wrong, please re-read the entire thread of
Annotations and then get back to me with a single message on thread
where actually had a discussion with some mature content instead of
personal feelings.

Regards,

On 9 May 2011 15:44, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:

It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.

But surely it is a motivational factor to learn C, and have a go at
implementing the feature yourself! That's what Open Source is all
about. If you don't like the feature, or it is missing one, DO
something about it. Saying that the developers are "not interested"
isn't really doing anything.

You really can't expect volunteers to simply down tools from family,
life, paid work to jump through hoops, attempting to make sense of
every user's request. No matter how loud they shout.

Now. If you had a pot (and a big pot) of money, then maybe you could
sponsor some developers for your pet peeve. I'll take your money.

As a volunteer to the PHP project (mainly making an arse of myself in
as many places as possible) and a PHP user, I am deeply indebted to
all the work undertaken by the core devs. I get paid because of them.

Please treat the devs nicely is all I'm really saying.

Richard.

Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

--

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

14 years ago by Rasmus Lerdorf — view source

unread

Hi Richard,

Again what I commented on other thread and again you barely see what I
mentioned, the feature is ALREADY written in C and compatible with
latest PHP trunk.
I'm not bitching against do and don't dos... I'm bitching about
ignored feature that are not even discussed.

I agree with you, it's an Open Source project and any help from any
front is valuable.
But as I pointed out on other thread, only developers with php-src
karma had features evaluated.
If you think I'm wrong, please re-read the entire thread of
Annotations and then get back to me with a single message on thread
where actually had a discussion with some mature content instead of
personal feelings.

A lot of people who understand the problem very well weighed in on this
feature. Framework authors and others who have a real use for
annotations, and there was still no clear agreement.

As far as RFCs on the wiki only coming from people with php-src
accounts, that is true, since that is our auth system for the wiki. But
getting an account, even if it is simply to submit an RFC to the wiki is
rather trivial.

Or looking at it another way, if the feature is so popular, getting one
of the 2000 people with an account to submit the RFC shouldn't be a problem.

-Rasmus

14 years ago by guilhermeblanco@gmail.com — view source

unread

Rasmus,

I already wrote an RFC, I already wrote a patch and none from php-src
gave me some valuable feedback.
During private conversations while flaming messages were popping on ML
thread, I updated the code to be more PHP compatible and when I went
to update the RFC on wiki, it became offline.

BTW, if you think Annotations wouldn't be so popular, please tell the
Symfony users (Routing, Validation), Doctrine users (Entire Mapping),
Typo3 users, Zend Framework (XML-RPC), PHPUnit users that this feature
is useless. If this doesn't count 2000 users using the feature, I
think only wordpress users may count this.

Cheers,

Hi Richard,

Again what I commented on other thread and again you barely see what I
mentioned, the feature is ALREADY written in C and compatible with
latest PHP trunk.
I'm not bitching against do and don't dos... I'm bitching about
ignored feature that are not even discussed.

I agree with you, it's an Open Source project and any help from any
front is valuable.
But as I pointed out on other thread, only developers with php-src
karma had features evaluated.
If you think I'm wrong, please re-read the entire thread of
Annotations and then get back to me with a single message on thread
where actually had a discussion with some mature content instead of
personal feelings.

A lot of people who understand the problem very well weighed in on this
feature. Framework authors and others who have a real use for annotations,
and there was still no clear agreement.

As far as RFCs on the wiki only coming from people with php-src accounts,
that is true, since that is our auth system for the wiki. But getting an
account, even if it is simply to submit an RFC to the wiki is rather
trivial.

Or looking at it another way, if the feature is so popular, getting one of
the 2000 people with an account to submit the RFC shouldn't be a problem.

-Rasmus

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

14 years ago by Rasmus Lerdorf — view source

unread

Rasmus,

I already wrote an RFC, I already wrote a patch and none from php-src
gave me some valuable feedback.
During private conversations while flaming messages were popping on ML
thread, I updated the code to be more PHP compatible and when I went
to update the RFC on wiki, it became offline.

BTW, if you think Annotations wouldn't be so popular, please tell the
Symfony users (Routing, Validation), Doctrine users (Entire Mapping),
Typo3 users, Zend Framework (XML-RPC), PHPUnit users that this feature
is useless. If this doesn't count 2000 users using the feature, I
think only wordpress users may count this.

Nobody has argued that there isn't a use for annotations. There
obviously is. The argument is whether it needs to be in the core of the
language when it isn't inherently a runtime thing. A single standard for
annotations and non-runtime tools for manipulating that standard is a
viable approach as well. That is what people are doing now, except they
all picked different ways of doing it. By putting it into the core you
are solving that problem since everyone will likely switch to it, but
the argument is that that is not a good enough justification for putting
it into the core of the language.

-Rasmus

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi Rasmus,

Thanks a lot for the response. This was the first email that I got
that is not rude against my patch.

I have worked on Doctrine annotations support (which is being used by
Symfony and also Typo3), which is a LL(*) parser that processes
docblocks and uses runtime classes to build associated information.
This relies on 2 points to correctly work: a reader and a cache. These
ones are required for 2 reasons:

PHP doesn't currently support annotations (so
ReflecionClass/ReflectionProperty/ReflectionMethod cannot have a
simplified API to getAnnotations()). The Reader is a composition over
ReflectionAPI.
Parsing is expensive and I cannot plugin opcache. To fix the
overhead of processing every request, I plugged a cache support.

What I thought it could be changed is:

Allow PHP to support it natively and also take advantage of opcode cache
Make API cleaner

That's where the idea came.
I voted for having it native to ZE because a code with and without
comments should behave the same. So this made me to work on something
that could be merged into php-src.

If possible, could you look at the patch and give me high level ideas
of what could be changed?

Thanks

Rasmus,

I already wrote an RFC, I already wrote a patch and none from php-src
gave me some valuable feedback.
During private conversations while flaming messages were popping on ML
thread, I updated the code to be more PHP compatible and when I went
to update the RFC on wiki, it became offline.

BTW, if you think Annotations wouldn't be so popular, please tell the
Symfony users (Routing, Validation), Doctrine users (Entire Mapping),
Typo3 users, Zend Framework (XML-RPC), PHPUnit users that this feature
is useless. If this doesn't count 2000 users using the feature, I
think only wordpress users may count this.

Nobody has argued that there isn't a use for annotations. There obviously
is. The argument is whether it needs to be in the core of the language when
it isn't inherently a runtime thing. A single standard for annotations and
non-runtime tools for manipulating that standard is a viable approach as
well. That is what people are doing now, except they all picked different
ways of doing it. By putting it into the core you are solving that problem
since everyone will likely switch to it, but the argument is that that is
not a good enough justification for putting it into the core of the
language.

-Rasmus

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

14 years ago by Stas Malyshev — view source

unread

Hi!

If possible, could you look at the patch and give me high level ideas
of what could be changed?

If the patch is the same RFC that is at
https://wiki.php.net/rfc/annotations, the same problems that were voiced
a number of times on the list stay:

it is overly complex (see class User example - it's really a piece of
code, I think it should be in the code)
it introduces method call syntax not compatible with the rest of PHP
it introduces object instantiation syntax not compatible with the rest
of PHP

These issues were mentioned before - were they fixed?
The RFC also does not clarify where the code contained in annotations is
run and how it would play with bytecode caches.

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

14 years ago by Ferenc Kovacs — view source

unread

On Mon, May 9, 2011 at 8:35 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

If possible, could you look at the patch and give me high level ideas

of what could be changed?

If the patch is the same RFC that is at
https://wiki.php.net/rfc/annotations, the same problems that were voiced a
number of times on the list stay:

it is overly complex (see class User example - it's really a piece of
code, I think it should be in the code)

it introduces method call syntax not compatible with the rest of PHP

it introduces object instantiation syntax not compatible with the rest of
PHP

These issues were mentioned before - were they fixed?
The RFC also does not clarify where the code contained in annotations is
run and how it would play with bytecode caches.

please read the other thread, I brought up the original thread (the more php
friendly version), as it was mentioned, the rfc didn't up to date AFAIK.

Tyrael

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi Stas,

Comments inline.

Hi!

If possible, could you look at the patch and give me high level ideas
of what could be changed?

If the patch is the same RFC that is at
https://wiki.php.net/rfc/annotations, the same problems that were voiced a
number of times on the list stay:

Currently it's not.
When I was going to update it, wiki went offline.

it is overly complex (see class User example - it's really a piece of
code, I think it should be in the code)

That's just an example. I'll simplify it.
The main point there was to illustrate the ability to support nested
annotations. Exmaple using @:

@A(@B)

it introduces method call syntax not compatible with the rest of PHP

it introduces object instantiation syntax not compatible with the rest of
PHP

This is already fixed.
@A(@B) would require class A like this:

class A {
public function __construct(B $b) { ... }
}

class B {}

These issues were mentioned before - were they fixed?

So your short answer is yes. =)

The RFC also does not clarify where the code contained in annotations is run
and how it would play with bytecode caches.

Sorry, this was one of the things that I was going to update. I'll
include it too.

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

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

14 years ago by Mike Willbanks — view source

unread

Guilherme,

As per many of the conversations on annotations one of that hardest parts of
it is that there are generally 3 conversations going on about it when this
starts to be discussed. It seems many threads are hi-jacked and I can
understand why.

I would like to state that annotations in the core may be a good idea;
however, we have PECL and PECL seems like the perfect place for this. Quite
a few extensions have started off in PECL and made their way to the core and
several have been moved from the core to PECL. To me annotations support
seems like it would be perfect in PECL. Dedicated machines and virtual
machines for end users are higher than ever and they seem to continue to
grow. This should easily allow folks to put in the PECL module as needed.

I would argue that the introduction of this into the core is adding more
feature bloat into the language that is not quite needed at this point.
There are obviously several improvements that this would allow to be
improved and consistent: WSDL / JSON-RPC / XML-RPC / Doctrine / etc.

However, I feel extensions like Mongo / Memcached / Gearman have more to add
to the PHP core than adding annotations and they live in PECL. Just
speaking from the practical point of view. It is great that certain
projects that have utilized annotations and created a layer in user land to
make annotations a nice thing to utilize. But to continue to argue this
point; it just does not seem logical other than the fact that a few projects
want to promote annotations should cause it to drop into the core.

I for one would like to see this go to PECL and see the up-take then
identify if it is needed for the next PHP release after 5.4. It seems a bit
early and like it would be crammed into the PHP core without enough
discussion. There are obviously many thoughts on this and it will take time
to sort out and implementation details then would be further down the trail
after some consensus is happening within this feature.

Regards,

Mike

14 years ago by Pierrick Charron — view source

unread

Hi,

Annotations as proposed in the RFC can not (or hardly) be develop as an
extension (and so can not go into PECL). The proposed feature require
modifications directly into the Zend Engine like for the inclusion of a new
syntax which imply modification of the parser.

Regards,
Pierrick

Guilherme,

As per many of the conversations on annotations one of that hardest parts
of
it is that there are generally 3 conversations going on about it when this
starts to be discussed. It seems many threads are hi-jacked and I can
understand why.

I would like to state that annotations in the core may be a good idea;
however, we have PECL and PECL seems like the perfect place for this.
Quite
a few extensions have started off in PECL and made their way to the core
and
several have been moved from the core to PECL. To me annotations support
seems like it would be perfect in PECL. Dedicated machines and virtual
machines for end users are higher than ever and they seem to continue to
grow. This should easily allow folks to put in the PECL module as needed.

I would argue that the introduction of this into the core is adding more
feature bloat into the language that is not quite needed at this point.
There are obviously several improvements that this would allow to be
improved and consistent: WSDL / JSON-RPC / XML-RPC / Doctrine / etc.

However, I feel extensions like Mongo / Memcached / Gearman have more to
add
to the PHP core than adding annotations and they live in PECL. Just
speaking from the practical point of view. It is great that certain
projects that have utilized annotations and created a layer in user land to
make annotations a nice thing to utilize. But to continue to argue this
point; it just does not seem logical other than the fact that a few
projects
want to promote annotations should cause it to drop into the core.

I for one would like to see this go to PECL and see the up-take then
identify if it is needed for the next PHP release after 5.4. It seems a
bit
early and like it would be crammed into the PHP core without enough
discussion. There are obviously many thoughts on this and it will take
time
to sort out and implementation details then would be further down the trail
after some consensus is happening within this feature.

Regards,

Mike

14 years ago by Drak — view source

unread

I would argue that the introduction of this into the core is adding more
feature bloat into the language that is not quite needed at this point.

Annotations cannot be considered bloat because are being used increasingly
everywhere that is a clear indication that they are required as part of the
PHP core as much as many of the Spl classes. It should be clear by now that
the PHP community really do want annotations. At this stage, if someone has
done the work to make this happen, the discussion really should be more
about polishing that contribution and making sure it provides a robust
solution to this feature than trying to postpone or find reasons to put this
off.

Regards,

Drak

14 years ago by Lester Caine — view source

unread

Drak wrote:

I would argue that the introduction of this into the core is adding more
feature bloat into the language that is not quite needed at this point.

Annotations cannot be considered bloat because are being used increasingly
everywhere that is a clear indication that they are required as part of the
PHP core as much as many of the Spl classes. It should be clear by now that
the PHP community really do want annotations. At this stage, if someone has
done the work to make this happen, the discussion really should be more
about polishing that contribution and making sure it provides a robust
solution to this feature than trying to postpone or find reasons to put this
off.

IS it clear by now that the majority of users want this? And the argument that
'You don't have to use it' does not wash either since once it has been pushed
in, some of the libraries we are using are going to start requiring it simply
because those developers do like the idea, but it does not necessarily mean that
THE CURRENT PROPOSAL is the right way of doing it? What I seem to have lost is
the evidence that annotations are going in because we HAVE all agreed to them?
If they CAN'T be implemented as a PECL extension, then they need a very good
implementation covering all aspects even before it is decided that they should
be pushed in? Much like Traits ...

The current standards such as phpdoc are falling well behind because nobody has
the time to implement some of the ALREADY created new features. It is this that
is more annoying given the investment in time just to try and keep up, And
creating tools intended for users who don't like the existing tools is further
watering down the project :( The existing tools had been working well, but
nowadays things are simply becoming a mess ...

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

14 years ago by Pascal COURTOIS — view source

unread

Le 10/05/2011 07:46, Lester Caine a écrit :

The existing tools had been working well, but nowadays things are simply becoming a mess ...

I agree.

Why not fixing the several hundreds of bugs in PHP before just even thinking about adding new features ???
I much respect people using my programs thus for my projects I just forbid myself to release any new
version which is not bug free as far as I know.

It's getting harder and harder to make my php programs work because of memory leaks/corruptions :-(

YMMV

14 years ago by Chad Fulton — view source

unread

IS it clear by now that the majority of users want this?

For what it's worth, I still oppose Annotations.

And the argument
that 'You don't have to use it' does not wash either since once it has been
pushed in, some of the libraries we are using are going to start requiring
it simply because those developers do like the idea, but it does not
necessarily mean that THE CURRENT PROPOSAL is the right way of doing it?

I especially oppose the complexity of the current proposal. One of the
reasons I prefer PHPDoc to the proposed Annotations is because they're
a simple key=>value syntax.

I'm already doing my coding in PHP - why do I have to code in a new
sub-language when all I want is a litte bit of meta-data?

My main question is: Why do we need more than key=>value? When you say
that "everyone" supports annotations (if that is true), are you sure
they actually want more than key=>value?

Discussion of this does not seem to appear in your "Why do we need
Class Metadata?" section.

14 years ago by Ferenc Kovacs — view source

unread

IS it clear by now that the majority of users want this?

For what it's worth, I still oppose Annotations.

And the argument
that 'You don't have to use it' does not wash either since once it has
been
pushed in, some of the libraries we are using are going to start
requiring
it simply because those developers do like the idea, but it does not
necessarily mean that THE CURRENT PROPOSAL is the right way of doing it?

I especially oppose the complexity of the current proposal. One of the
reasons I prefer PHPDoc to the proposed Annotations is because they're
a simple key=>value syntax.

that would be the same argument that we don't need objects because we have
arrays, and if you only need something to store your structures, then both
can be used for that.

I'm already doing my coding in PHP - why do I have to code in a new
sub-language when all I want is a litte bit of meta-data?

nobody is forcing you to use annotations, it won't replace the docblocks.

My main question is: Why do we need more than key=>value? When you say
that "everyone" supports annotations (if that is true), are you sure
they actually want more than key=>value?

at least Doctrine, Symfony and FLOW3 does.
Sebastian expressed that he is fine with the current Docblock support for
PHPUnit.
the FLOW3 used to use single key values in the past, but I'm not familiar
with the current situation.

for actual use-cases you can check
http://blog.seric.at/2011/05/03/annotations-with-symfony2/
or
http://www.doctrine-project.org/docs/orm/2.0/en/reference/annotations-reference.html#annref-column

Discussion of this does not seem to appear in your "Why do we need
Class Metadata?" section.

I also think that it would be a good idea to link or describe annotations in
general, because it seems that nobody bothers to read that up without
joining the conversation...

Tyrael

14 years ago by Lars Schultz — view source

unread

Am 10.05.2011 09:44, schrieb Ferenc Kovacs:

IS it clear by now that the majority of users want this?

For what it's worth, I still oppose Annotations.

And the argument
that 'You don't have to use it' does not wash either since once it has
been
pushed in, some of the libraries we are using are going to start
requiring
it simply because those developers do like the idea, but it does not
necessarily mean that THE CURRENT PROPOSAL is the right way of doing it?

I especially oppose the complexity of the current proposal. One of the
reasons I prefer PHPDoc to the proposed Annotations is because they're
a simple key=>value syntax.

that would be the same argument that we don't need objects because we have
arrays, and if you only need something to store your structures, then both
can be used for that.

I'm already doing my coding in PHP - why do I have to code in a new
sub-language when all I want is a litte bit of meta-data?

nobody is forcing you to use annotations, it won't replace the docblocks.

My main question is: Why do we need more than key=>value? When you say
that "everyone" supports annotations (if that is true), are you sure
they actually want more than key=>value?

at least Doctrine, Symfony and FLOW3 does.
Sebastian expressed that he is fine with the current Docblock support for
PHPUnit.
the FLOW3 used to use single key values in the past, but I'm not familiar
with the current situation.

for actual use-cases you can check
http://blog.seric.at/2011/05/03/annotations-with-symfony2/
or
http://www.doctrine-project.org/docs/orm/2.0/en/reference/annotations-reference.html#annref-column

Discussion of this does not seem to appear in your "Why do we need
Class Metadata?" section.

I also think that it would be a good idea to link or describe annotations in
general, because it seems that nobody bothers to read that up without
joining the conversation...

Tyrael

From the user-end perspective, what I don't understand is this:

What is the goal of having Annotations embedded in PHP? To nail down a
common syntax? To provide an interface for meta-information on a class?

Why can't this be PHP code? Why should I have to learn a whole new kind
of syntax? We already have a common syntax (PHP interface) for this as
well as an interface (static Class-functions/Object-methods).

To explain what I mean, I'll use the example provided in the RFC. Could
anyone please explain the advantages of having "passive" annotations
over "active" PHP Code.

<Entity("users")>
class User
{
<Column("integer")>
<Id>
<GeneratedValue("AUTO")>
protected $id;

 // ...

 <ManyToMany("Phonenumber")>
 protected $Phonenumbers;

}

*** Example ***

class User implements EntityAnnotation {
protected $id;
protected $Phonenumbers;

public function getEntityAnnotation(){
	return new User_EntityAnnotation();
}

}

class User_EntityAnnotation {
public function getEntityName(){
return 'users';
}

public function getColumnInfo($property){
	switch( $property ) {
		case 'id': return array(
			'column'=>'integer',
			'isPrimary'=>true,
			'autoIncrement'=>true
		);
		
		case 'Phonenumbers': return array(
			'manytomany'=>'Phonenumber'
		);
    }
 }

}

14 years ago by Jordi Boggiano — view source

unread

On Tue, May 10, 2011 at 10:02 AM, Lars Schultz
lars.schultz@toolpark.com wrote:

What is the goal of having Annotations embedded in PHP? To nail down a
common syntax? To provide an interface for meta-information on a class?

I think the main reasons are standardization of the syntax and
performance of the parsing. At the moment everyone has to cache the
stuff because hitting the tokenizer every time is quite expensive.

Honestly if there was a way to parse them into the docblocks, I think
it would be better because it would allow us to keep BC with older PHP
versions, but since docblocks contain documentation as well, I think
you can't really parse it all without creating a mess.

Why can't this be PHP code? Why should I have to learn a whole new kind of
syntax? We already have a common syntax (PHP interface) for this as well as
an interface (static Class-functions/Object-methods).

Annotations are not code, but more like metadata to tell the
surrounding libraries how to work best with a piece of code.

To explain what I mean, I'll use the example provided in the RFC. Could
anyone please explain the advantages of having "passive" annotations over
"active" PHP Code.

I think your example shows very well why annotations are good, it's
much more concise.

Cheers

--
Jordi Boggiano
@seldaek :: http://seld.be/

14 years ago by Lars Schultz — view source

unread

Am 10.05.2011 10:10, schrieb Jordi Boggiano:

I think the main reasons are standardization of the syntax and
performance of the parsing. At the moment everyone has to cache the
stuff because hitting the tokenizer every time is quite expensive.
If implemented within PHP the existing opcode-caches could work wonders
on this.

Annotations are not code, but more like metadata to tell the
surrounding libraries how to work best with a piece of code.
What is code?;) What's the Problem with having meta-data within PHP-Code?

I think your example shows very well why annotations are good, it's
much more concise.
But my example is much more verbose (which is good in my view), uses
common syntax and is very flexible! It gives you the whole power of PHP
instead of a semi-language (no offense).

14 years ago by Rasmus Lerdorf — view source

unread

On Tue, May 10, 2011 at 10:02 AM, Lars Schultz

To explain what I mean, I'll use the example provided in the RFC. Could
anyone please explain the advantages of having "passive" annotations over
"active" PHP Code.

I think your example shows very well why annotations are good, it's
much more concise.

By concise, you mean shorter, easier to read?

I have a really hard time looking at:

<Entity("users")>
class User {
<Column("integer")>
<Id>
<GeneratedValue("AUTO")>
<ManyToMany("Phonenumber")>
protected $Phonenumbers;
}

as a PHP user and instantly understanding what this does. It looks
completely foreign from a PHP syntax point of view.

Whereas:

class User_EntityAnnotation {
public function getEntityName() {
return 'users';
}

 public function getColumnInfo($property) {
     switch($property) {
         case 'id': return array(
             'column'=>'integer',
             'isPrimary'=>true,
             'autoIncrement'=>true
         );

         case 'Phonenumbers': return array(
             'manytomany'=>'Phonenumber'
         );
     }
 }

}

is way more verbose, but I can instantly grok what is going on without
learning a new syntax, without waiting for my opcode cache to support
it, and without waiting for my editor to understand the new syntax.

Don't underestimate the difficulty in getting opcode cache support for
something like this. If you think the engine code is complex, try
digging into the opcode cache code. It will be much much harder to write
the opcode cache support than it was to write the engine code for it.

I also have a personal problem with code that needs to introspect on
every web request in order to run. But that is likely because I am old
and gray and used to stare sceptically at the assembly output of the
first C compilers to see if I could come up with an alternative that
would take fewer cycles.

-Rasmus

14 years ago by Martin Scotta — view source

unread

On Tue, May 10, 2011 at 10:02 AM, Lars Schultz

To explain what I mean, I'll use the example provided in the RFC. Could

anyone please explain the advantages of having "passive" annotations over
"active" PHP Code.

I think your example shows very well why annotations are good, it's
much more concise.

By concise, you mean shorter, easier to read?

I have a really hard time looking at:

<Entity("users")>
class User {
<Column("integer")>
<Id>
<GeneratedValue("AUTO")>
<ManyToMany("Phonenumber")>
protected $Phonenumbers;
}

as a PHP user and instantly understanding what this does. It looks
completely foreign from a PHP syntax point of view.

Whereas:

class User_EntityAnnotation {
public function getEntityName() {
return 'users';
}

public function getColumnInfo($property) {
switch($property) {
case 'id': return array(
'column'=>'integer',
'isPrimary'=>true,
'autoIncrement'=>true
);
       case 'Phonenumbers': return array(
           'manytomany'=>'Phonenumber'
       );
   }
}
}

is way more verbose, but I can instantly grok what is going on without
learning a new syntax, without waiting for my opcode cache to support it,
and without waiting for my editor to understand the new syntax.

The editor argument is out of place
do you really think that the engine should we built around what IDE
supports?

Don't underestimate the difficulty in getting opcode cache support for
something like this. If you think the engine code is complex, try digging
into the opcode cache code. It will be much much harder to write the opcode
cache support than it was to write the engine code for it.

I also have a personal problem with code that needs to introspect on every
web request in order to run. But that is likely because I am old and gray
and used to stare sceptically at the assembly output of the first C
compilers to see if I could come up with an alternative that would take
fewer cycles.

-Rasmus

14 years ago by Lars Schultz — view source

unread

Am 10.05.2011 14:28, schrieb Martin Scotta:

The editor argument is out of place
do you really think that the engine should we built around what IDE
supports?

At least the much quoted user-base would welcome syntax-support for this
feature, wouldn't you agree? If support is already there, that's a big plus!

14 years ago by Lester Caine — view source

unread

Lars Schultz wrote:

Am 10.05.2011 14:28, schrieb Martin Scotta:

The editor argument is out of place
do you really think that the engine should we built around what IDE
supports?

At least the much quoted user-base would welcome syntax-support for this
feature, wouldn't you agree? If support is already there, that's a big
plus!

And given the amount of time it is taking to get things like GIT and HG even
vaguely functional in Eclipse and other IDE's who is expected to implement even
the existing new features. Even the classname stuff still needs someone to
support it in the IDE's :(

As an interesting aside, HG is based on python2 and now that python3 is out
questions are being asked about supporting that, but the core development team
do not have the time since the two will not be backwards compatible. So it's not
just PHP that is having difficulties bringing the user base along with these new
developments. I'm only just getting a handle on python2 so that I can integrate
my hg repo's with the rest of my PHP based code management ....

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

14 years ago by Christopher Jones — view source

unread

The editor argument is out of place do you really think that the
engine should we built around what IDE supports?

IDEs are part of the PHP ecosystem, just as much as frameworks, op
code caches, documentation, bug reports, maintenance issues and even
current technology trends. The benefits of a new feature must be
calculated taking into account its impact on the whole ecosystem.

Chris

--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/

14 years ago by Ferenc Kovacs — view source

unread

On Tue, May 10, 2011 at 8:16 PM, Christopher Jones <
christopher.jones@oracle.com> wrote:

The editor argument is out of place do you really think that the

engine should we built around what IDE supports?

IDEs are part of the PHP ecosystem, just as much as frameworks, op
code caches, documentation, bug reports, maintenance issues and even
current technology trends. The benefits of a new feature must be
calculated taking into account its impact on the whole ecosystem.

creating an official EBNF would solve this problem, among others as well.
http://marc.info/?l=php-internals&m=129387252319019

patches welcome ;)

Tyrael

14 years ago by johannes@schlueters.de — view source

unread

creating an official EBNF would solve this problem, among others as well.
http://marc.info/?l=php-internals&m=129387252319019

patches welcome ;)

A formal syntax description might help with highligting, not with all
assisting features an IDE provides (good and useful autocomplete, having
some visualisation of the code structure ("class tree" incl. annotation)
and all these)

The main point in regards to IDEs and such thing imo is that it shows
how long it takes for the eco system to pick a change up. The result is
that it takes "ages" till a new standard can be relied upon. This is
worse for a new syntax as there is no way to have code compatible with
5.4 and 5.3 then. There focussing around the existing way (doc block,
more efficient doc block parsing, ...) helps.

Then again "proper" annotations might solve tomorrows problem.

johannes, who does not argue about annotations themselves

14 years ago by Lester Caine — view source

unread

Christopher Jones wrote:

The editor argument is out of place do you really think that the
engine should we built around what IDE supports?

IDEs are part of the PHP ecosystem, just as much as frameworks, op
code caches, documentation, bug reports, maintenance issues and even
current technology trends. The benefits of a new feature must be
calculated taking into account its impact on the whole ecosystem.

And many of us do not recognise some of the 'complaints' simply because our own
ecosystems have already solved the problem, but it's these 'new developments'
that are threatening to destroy a perfectly stable system.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

14 years ago by Ferenc Kovacs — view source

unread

Christopher Jones wrote:

The editor argument is out of place do you really think that the

engine should we built around what IDE supports?

IDEs are part of the PHP ecosystem, just as much as frameworks, op
code caches, documentation, bug reports, maintenance issues and even
current technology trends. The benefits of a new feature must be
calculated taking into account its impact on the whole ecosystem.

And many of us do not recognise some of the 'complaints' simply because our
own ecosystems have already solved the problem, but it's these 'new
developments' that are threatening to destroy a perfectly stable system.

sorry my FUD counter just overflowed with your last comment.

Tyrael

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi all,

Based on an extensive chat with Matthew, I think we reached some consensus.
I'll write another RFC related to Annotations in docblocks, then we
can chat until reach some standardization and availability.

I'll keep the old one for history purposes. It seems that none from
core php devs accepted it, so I'll move it to rejected.
As I told you previously, all I wanted was some good feedback to give
a north and that's what I had.

As soon as I finish the new RFC, I'll open another thread here for
fine-grain the support and discuss architecture.
I'll keep Stas comments in mind when creating it, so it would help in
discussions. It seems we still have 2 weeks to discuss the new idea
and less than 2 months to get it ready if everyone agreed.

Regards,

Christopher Jones wrote:

The editor argument is out of place do you really think that the

engine should we built around what IDE supports?

IDEs are part of the PHP ecosystem, just as much as frameworks, op
code caches, documentation, bug reports, maintenance issues and even
current technology trends. The benefits of a new feature must be
calculated taking into account its impact on the whole ecosystem.

And many of us do not recognise some of the 'complaints' simply because our
own ecosystems have already solved the problem, but it's these 'new
developments' that are threatening to destroy a perfectly stable system.

sorry my FUD counter just overflowed with your last comment.

Tyrael

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

14 years ago by Rasmus Lerdorf — view source

unread

Hi all,

Based on an extensive chat with Matthew, I think we reached some consensus.
I'll write another RFC related to Annotations in docblocks, then we
can chat until reach some standardization and availability.

I'll keep the old one for history purposes. It seems that none from
core php devs accepted it, so I'll move it to rejected.
As I told you previously, all I wanted was some good feedback to give
a north and that's what I had.

As soon as I finish the new RFC, I'll open another thread here for
fine-grain the support and discuss architecture.
I'll keep Stas comments in mind when creating it, so it would help in
discussions. It seems we still have 2 weeks to discuss the new idea
and less than 2 months to get it ready if everyone agreed.

One suggestion. Be very careful about anything that requires changes in
the opcode caches out there. Such changes will be very slow in coming,
if at all.

-Rasmus

14 years ago by Drak — view source

unread

One suggestion. Be very careful about anything that requires changes in the
opcode caches out there. Such changes will be very slow in coming, if at
all.

It's unrelated to this thread but, what is the status of merging APC
into the PHP core? I remember this being discussed at some point.

Drak

14 years ago by Rasmus Lerdorf — view source

unread

One suggestion. Be very careful about anything that requires changes in the
opcode caches out there. Such changes will be very slow in coming, if at
all.

It's unrelated to this thread but, what is the status of merging APC
into the PHP core? I remember this being discussed at some point.

Next major release. We don't have enough manpower to do it for 5.4.
Right now it is only Gopal that is working on that code. Once we merge
it is going to take people quite a while to get their heads around it.

-Rasmus

14 years ago by Chad Fulton — view source

unread

On Tue, May 10, 2011 at 12:35 PM, guilhermeblanco@gmail.com
guilhermeblanco@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

14 years ago by Mike van Riel — view source

unread

On Tue, May 10, 2011 at 12:35 PM, guilhermeblanco@gmail.com
guilhermeblanco@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

14 years ago by Ferenc Kovacs — view source

unread

On Wed, May 11, 2011 at 2:36 PM, Mike van Riel mike.vanriel@naenius.comwrote:

On Tue, May 10, 2011 at 12:35 PM, guilhermeblanco@gmail.com
guilhermeblanco@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

14 years ago by Lester Caine — view source

unread

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

14 years ago by Mike van Riel — view source

unread

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)

14 years ago by Ferenc Kovacs — view source

unread

On Wed, May 11, 2011 at 3:27 PM, Mike van Riel mike.vanriel@naenius.comwrote:

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

14 years ago by Lester Caine — view source

unread

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

14 years ago by Matthew Weier O'Phinney — view source

unread

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

14 years ago by Sebastian Bergmann — view source

unread

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 Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

14 years ago by Sebastian Bergmann — view source

unread

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 Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

14 years ago by Mike van Riel — view source

unread

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

14 years ago by Sebastian Bergmann — view source

unread

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 Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

14 years ago by Lester Caine — view source

unread

Ferenc Kovacs wrote:

sorry my FUD counter just overflowed with your last comment.
Sorry you feel that way, but obviously there are more people with my view that
we simply do not agree on IF annotation should be implemented. I'm a lot more
comfortable with something that works WITH what we already have rather than
going off on yet another tangent. Tidying existing docblock content to an
updated format makes a lot more sense then having to do a wholesale re-write
many thousands of files. Adding another copy of much of the same data in a
complete different format is equally insane?

PDO is another case in point - that is still not accepted and fully functional
as a replacement for the genric drivers ... ADOdb still provides a valid
abstraction layer, and if you must use PDO then it just loads that instead of
the generic one ... and it runs just as fast on either. PDO is functional, but
needs more work, however there are few people that find the need for improving it?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi Lester,

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

--

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

14 years ago by Lester Caine — view source

unread

guilhermeblanco@gmail.com wrote:

Hi Lester,

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

14 years ago by Lester Caine — view source

unread

Rasmus Lerdorf wrote:

I also have a personal problem with code that needs to introspect on
every web request in order to run. But that is likely because I am old
and gray and used to stare sceptically at the assembly output of the
first C compilers to see if I could come up with an alternative that
would take fewer cycles.

AND fit it into the 16k of core store which was all an ICL1900 computer had to
run on ...

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

14 years ago by Martin Scotta — view source

unread

Martin Scotta

On Tue, May 10, 2011 at 5:02 AM, Lars Schultz lars.schultz@toolpark.comwrote:

Am 10.05.2011 09:44, schrieb Ferenc Kovacs:

On Tue, May 10, 2011 at 9:01 AM, Chad Fultonchadfulton@gmail.com

wrote:

On Mon, May 9, 2011 at 10:46 PM, Lester Cainelester@lsces.co.uk

wrote:

IS it clear by now that the majority of users want this?

For what it's worth, I still oppose Annotations.

And the argument

that 'You don't have to use it' does not wash either since once it has

been

pushed in, some of the libraries we are using are going to start

requiring

it simply because those developers do like the idea, but it does not
necessarily mean that THE CURRENT PROPOSAL is the right way of doing it?

I especially oppose the complexity of the current proposal. One of the
reasons I prefer PHPDoc to the proposed Annotations is because they're
a simple key=>value syntax.

that would be the same argument that we don't need objects because we have
arrays, and if you only need something to store your structures, then both
can be used for that.

I'm already doing my coding in PHP - why do I have to code in a new
sub-language when all I want is a litte bit of meta-data?

nobody is forcing you to use annotations, it won't replace the docblocks.

My main question is: Why do we need more than key=>value? When you say
that "everyone" supports annotations (if that is true), are you sure
they actually want more than key=>value?

at least Doctrine, Symfony and FLOW3 does.
Sebastian expressed that he is fine with the current Docblock support for
PHPUnit.
the FLOW3 used to use single key values in the past, but I'm not familiar
with the current situation.

for actual use-cases you can check
http://blog.seric.at/2011/05/03/annotations-with-symfony2/
or

http://www.doctrine-project.org/docs/orm/2.0/en/reference/annotations-reference.html#annref-column

Discussion of this does not seem to appear in your "Why do we need
Class Metadata?" section.

I also think that it would be a good idea to link or describe annotations
in
general, because it seems that nobody bothers to read that up without
joining the conversation...

Tyrael

From the user-end perspective, what I don't understand is this:

What is the goal of having Annotations embedded in PHP? To nail down a
common syntax? To provide an interface for meta-information on a class?

Why can't this be PHP code? Why should I have to learn a whole new kind of
syntax? We already have a common syntax (PHP interface) for this as well as
an interface (static Class-functions/Object-methods).

To explain what I mean, I'll use the example provided in the RFC. Could
anyone please explain the advantages of having "passive" annotations over
"active" PHP Code.

Annotated code integrates best with library/frameworks without the need to
"extends" or "implements".
Without annotation you will need to extend some class or to implement some
interface. That means more code to write, more chances to shoot you foot.

With annotation your classes are unaware of the other components, which
implies:

shorter, concise code => less bugs
no extra dependencies => easy to test

class UserFoo extends LibraryFoo { }
class UserBar implements LibraryBar {
// even worst you will need to write some methods here
}

With annotations classes are "free" to live on you own herarchy

<LibraryFoo> class UserFoo extends UserFooBase { }
<LibraryBar> class UserBar { }

<Entity("users")>
class User
{
<Column("integer")>
<Id>
<GeneratedValue("AUTO")>
protected $id;

// ...

<ManyToMany("Phonenumber")>
protected $Phonenumbers;
}

*** Example ***

class User implements EntityAnnotation {
protected $id;
protected $Phonenumbers;
   public function getEntityAnnotation(){
           return new User_EntityAnnotation();
   }
}

class User_EntityAnnotation {
public function getEntityName(){
return 'users';
}
   public function getColumnInfo($property){
           switch( $property ) {
                   case 'id': return array(
                           'column'=>'integer',
                           'isPrimary'=>true,
                           'autoIncrement'=>true
                   );

                   case 'Phonenumbers': return array(
                           'manytomany'=>'Phonenumber'
                   );
       }
}
}

14 years ago by Lars Schultz — view source

unread

Am 10.05.2011 14:47, schrieb Martin Scotta:

Annotated code integrates best with library/frameworks without the need to
"extends" or "implements".
Without annotation you will need to extend some class or to implement some
interface. That means more code to write, more chances to shoot you foot.
Umm. Is there any way with the Annotation-proposal to validate a class
to have all the necessary annotations to work with a certain framework?
Is there an annotation-Schema or DTD which I can apply against my
classes and validate them? Because that's what you get when using
interfaces. Which means less "shooting in the foot".

As for writing less code...If there is any shared code, we now have
traits!;) hurray!

With annotation your classes are unaware of the other components, which
implies:

shorter, concise code => less bugs

no extra dependencies => easy to test

class UserFoo extends LibraryFoo { }
I can see that extending does not really work when using frameworks. But
when using interfaces and traits in conjunction, this is not necessary
anymore.

class UserBar implements LibraryBar {
// even worst you will need to write some methods here
}
I don't get what the problem with writing methods is. They are readable
by any PHP5 developer and you get all kind of support in writing them.

With annotations classes are "free" to live on you own herarchy
The same holds true for interfaces.

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi,

You all think that mapping something can always be abstracted into a
few lines like the one you presented.
Well, in certain cases your idea is valid. I'd then point you an
Entity mapping of Doctrine 2 with and without Annotations, so you can
imagine how much it can abstract:

With Doctrine Annotations: http://pastie.org/1885284
With my proposal: http://pastie.org/1885294
Without Annotations: http://pastie.org/1885252

Is that still simple?

Regarding usability, I thought that it is not "it must be used by
10,000k people to be relevant".
I think the best thing that can prove that is "goto". I didn't see a
lot of people requesting for it, but it was still included.
Let me ask you then: if it wasn't widely requested (considering your
argument that only massive requests should be relevant), why was it
included?

Regarding BC, IDEs, etc... Traits also includes new keywords and none
complained about "IDE won't support immediately".
Should I consider then that your arguments that you are strongly
forcing to be valid on this subject should also be strong on traits?
If yes, why traits was included?

Regarding readability, traits and annotations follow a similar path.
Everything that annotations can do, with much more work PHP can do
too. The same applies to traits. So again I ask: if with PHP is
possible to do the same things that traits included, why was it
included?

I'm not putting traits support inclusion on risk. I'm a string +1 to it.
All I want is that you stop giving stupid arguments to be against the
patch instead of giving real relevant arguments.

Regards,

On Tue, May 10, 2011 at 11:12 AM, Lars Schultz
lars.schultz@toolpark.com wrote:

Am 10.05.2011 14:47, schrieb Martin Scotta:

Annotated code integrates best with library/frameworks without the need to
"extends" or "implements".
Without annotation you will need to extend some class or to implement some
interface. That means more code to write, more chances to shoot you foot.

Umm. Is there any way with the Annotation-proposal to validate a class to
have all the necessary annotations to work with a certain framework? Is
there an annotation-Schema or DTD which I can apply against my classes and
validate them? Because that's what you get when using interfaces. Which
means less "shooting in the foot".

As for writing less code...If there is any shared code, we now have
traits!;) hurray!

With annotation your classes are unaware of the other components, which
implies:

shorter, concise code => less bugs

no extra dependencies => easy to test

class UserFoo extends LibraryFoo { }

I can see that extending does not really work when using frameworks. But
when using interfaces and traits in conjunction, this is not necessary
anymore.

class UserBar implements LibraryBar {
// even worst you will need to write some methods here
}

I don't get what the problem with writing methods is. They are readable by
any PHP5 developer and you get all kind of support in writing them.

With annotations classes are "free" to live on you own herarchy

The same holds true for interfaces.

--

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

14 years ago by Lester Caine — view source

unread

guilhermeblanco@gmail.com wrote:

With Doctrine Annotations:http://pastie.org/1885284
With my proposal:http://pastie.org/1885294
Without Annotations:http://pastie.org/1885252

Is that still simple?
But exactly what is wrong with the first one. It does not require getting a book
out to work out what it means, and can easily be read by anybody who has been
programming for a while.

All I want is that you stop giving stupid arguments to be against the
patch instead of givingreal relevant arguments.
Give practical examples of why we HAVE to change from what is currently working
for many people already today? Why this is not simply being accepted is simply
becuase we are already doing the same thing happily other ways ....

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

14 years ago by Jonathan Bond-Caron — view source

unread

I'm not putting traits support inclusion on risk. I'm a string +1 to
it.
All I want is that you stop giving stupid arguments to be against the
patch instead of giving real relevant arguments.

Complexity:
http://en.wikipedia.org/wiki/Enterprise_JavaBean
Annotations serve as a good way for "application containers" to become relevant disguised as "developer productivity".

I know that whatever I say, you'll continue to support annotations religiously.

Calling everyone else arguments "stupid" is far from a discussion.

14 years ago by Lars Schultz — view source

unread

Am 10.05.2011 17:07, schrieb guilhermeblanco@gmail.com:

Is that still simple?
You bloated the php example unnecessarily. This contains the same
information as your Annotations example, which to me, is very similar.

http://pastie.org/1886774

14 years ago by guilhermeblanco@gmail.com — view source

unread

Not trying to be harsh, but I'm not bloating my PHP example.
That's the actual way Doctrine supports Metadata information. I can explain why.

Conceptually, an architectural design of an entity should not know
anything about its persistence information.
By that means, we cannot for example implement an interface (which
seems you have forgotten to add) or an abstract class for
"getAnnotations()" method.
If you enforce people to implement an abstract class or even an
interface, you bring 2 problems:

Entities with knowledge about its persistence information
Resources being wasted
You rely on an instance to grab information. Or you use a slow
approach of having a static method

The second argument is valid because in a request you're able to deal
with an average number of methods. Each method is a pointer of 4
bytes.
By having an "irrelevant" method on entity, you consume (on a page
with 500 entities), 2000 bytes of unnecessary resources.

The third argument is exactly what we had on Doctrine 1. We relied on
a ghost entity for metadata retrieval. This brings a whole new level
of issues to deal with.
Making it static, slow down a lot the overall ClassMetadata retrieval
information.

Also, there are much more things than you can actually think of related to this.
The code is not bloated. Since you don't have a "pre-processor" for
class metadatas, you have to build all definitions manually. This is
why you have to set inheritance type, for example.
$metadata->setInheritanceType(ClassMetadataInfo::INHERITANCE_TYPE_NONE);

FYI, Doctrine took an year of planning an another year of careful
implementation of each feature.
This means to you that every single feature was carefully planned,
optimized and implemented with performance, good OO design and
extensibility. =)

Cheers,

Am 10.05.2011 17:07, schrieb guilhermeblanco@gmail.com:

Is that still simple?

You bloated the php example unnecessarily. This contains the same
information as your Annotations example, which to me, is very similar.

http://pastie.org/1886774

--

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

14 years ago by Lars Schultz — view source

unread

Am 11.05.2011 00:28, schrieb guilhermeblanco@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.

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi Larz,

Am 11.05.2011 00:28, schrieb guilhermeblanco@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. =)

--

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

14 years ago by dukeofgaming — view source

unread

On Wed, May 11, 2011 at 12:29 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

Hi Larz,

On Wed, May 11, 2011 at 3:35 AM, Lars Schultz lars.schultz@toolpark.com
wrote:

Am 11.05.2011 00:28, schrieb guilhermeblanco@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?.

14 years ago by guilhermeblanco@gmail.com — view source

unread

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 12:29 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:

Hi Larz,

On Wed, May 11, 2011 at 3:35 AM, Lars Schultz lars.schultz@toolpark.com
wrote:

Am 11.05.2011 00:28, schrieb guilhermeblanco@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: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil

14 years ago by Marcelo Gornstein — view source

unread

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, guilhermeblanco@gmail.com
guilhermeblanco@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 12:29 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:

Hi Larz,

On Wed, May 11, 2011 at 3:35 AM, Lars Schultz lars.schultz@toolpark.com
wrote:

Am 11.05.2011 00:28, schrieb guilhermeblanco@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: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil

--

--

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

14 years ago by dukeofgaming — view source

unread

On Wed, May 11, 2011 at 4:57 PM, guilhermeblanco@gmail.com <
guilhermeblanco@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.

14 years ago by guilhermeblanco@gmail.com — view source

unread

@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 4:57 PM, guilhermeblanco@gmail.com
guilhermeblanco@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: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil

14 years ago by Jordi Boggiano — view source

unread

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/

14 years ago by Matthew Weier O'Phinney — view source

unread

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

I would argue that the introduction of this into the core is adding
more feature bloat into the language that is not quite needed at
this point.

Annotations cannot be considered bloat because are being used
increasingly everywhere that is a clear indication that they are
required as part of the PHP core as much as many of the Spl classes.
It should be clear by now that the PHP community really do want
annotations.

Can you back this up, please?

Just because developers are using annotations does not necessarily mean
we need a new syntax.

At this stage, if someone has done the work to make this
happen, the discussion really should be more about polishing that
contribution and making sure it provides a robust solution to this
feature than trying to postpone or find reasons to put this off.

I've gone on record as stating that annotations within docblocks are
sufficient, and would rather see native support for parsing docblocks
for annotations than introducing a new syntax. Others have stated the
same. I'd like to see why a new syntax is considered "necessary", and
why native support for docblock annotations is not considered a
reasonable path.

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

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi Matthew,

There's just one reason that it cannot be possible to do inside docblocks:

Code with and without comments should act the same.

Also, no matter if it's inside docblocks or not, we'd still have a new
syntax. No matter what you do. Even a key => value is a new syntax.
But it seems that none notice what I've been trying to express with
the patch: key => value is not enough.
Doctrine and Symfony are 2 projects that requires more than key/value
support, because annotations declaration requires state, something not
possible with k/v.

Anyway, someone asked me previously if other languages support
"complex" annotations like I suggest, my answer is YES and I even
included in RFC the links to .NET and Java implementation examples.

Cheers,

On Tue, May 10, 2011 at 12:57 PM, Matthew Weier O'Phinney
weierophinney@php.net wrote:

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

I would argue that the introduction of this into the core is adding
more feature bloat into the language that is not quite needed at
this point.

Annotations cannot be considered bloat because are being used
increasingly everywhere that is a clear indication that they are
required as part of the PHP core as much as many of the Spl classes.
It should be clear by now that the PHP community really do want
annotations.

Can you back this up, please?

Just because developers are using annotations does not necessarily mean
we need a new syntax.

At this stage, if someone has done the work to make this
happen, the discussion really should be more about polishing that
contribution and making sure it provides a robust solution to this
feature than trying to postpone or find reasons to put this off.

I've gone on record as stating that annotations within docblocks are
sufficient, and would rather see native support for parsing docblocks
for annotations than introducing a new syntax. Others have stated the
same. I'd like to see why a new syntax is considered "necessary", and
why native support for docblock annotations is not considered a
reasonable path.

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

--

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

14 years ago by Matthew Weier O'Phinney — view source

unread

There's just one reason that it cannot be possible to do inside docblocks:

Code with and without comments should act the same.

Why?

Would you expect phpDocumentor to work without docblocks? No.

Would you expect to know parameter types and return values without
docblock annotations? No.

In each of these cases, we know the capabilities based on the comment -
and we know that stripping out the comment and running specific tools on
the code will simply not work. I'd expect the same of annotations via
docblocks.

There are no good reasons to strip out docblock comments at this point
in PHP's history -- you don't gain speed, you don't improve parsing
time; about the only reason I can see to do so would be to minimize file
size for deployment -- and I'd argue even that is hard to justify.

So, in sum, if your code depends on annotations support, you know that
you cannot strip the comments. That's an easy rule to follow, and
doesn't require a new PHP syntax.

Also, no matter if it's inside docblocks or not, we'd still have a new
syntax. No matter what you do. Even a key => value is a new syntax.
But it seems that none notice what I've been trying to express with
the patch: key => value is not enough.
Doctrine and Symfony are 2 projects that requires more than key/value
support, because annotations declaration requires state, something not
possible with k/v.

This is very easy to support in userland. I'd argue that a
ReflectionDocComment class with the following signature would be
sufficient:

getShortDescription()
getLongDescription()
getAnnotations()
hasAnnotation($name)
getAnnotation($name)
setAnnotationParser($callback)

Annotations would be simply key/value pairs, and by default annotations
would be recognized using the already popular standard of
@annotationName, with the value being everything up to the next
annotation or the end of the docblock.

It would be up to the given annotation CONSUMER to determine how to
consume the value. With facilities such as json_decode(), you can
already even mimic native PHP structures to a large degree.

For cases where you want to utilize a different annotation format, the
ability to set an alternative parser would allow you to write such a
facility as an extension or in userland code, and its return value would
be used to seed the annotations accessors.

Anyway, someone asked me previously if other languages support
"complex" annotations like I suggest, my answer is YES and I even
included in RFC the links to .NET and Java implementation examples.

I'm not one of those people. I already know that the support exists
elsewhere. I'm simply not convinced we need anything outside of the
ability to grab annotations from docblocks -- something that can be done
in userland now, but which could be sped up with native extensions.

On Tue, May 10, 2011 at 12:57 PM, Matthew Weier O'Phinney
weierophinney@php.net wrote:

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

I would argue that the introduction of this into the core is adding
more feature bloat into the language that is not quite needed at
this point.

Annotations cannot be considered bloat because are being used
increasingly everywhere that is a clear indication that they are
required as part of the PHP core as much as many of the Spl classes.
It should be clear by now that the PHP community really do want
annotations.

Can you back this up, please?

Just because developers are using annotations does not necessarily mean
we need a new syntax.

At this stage, if someone has done the work to make this
happen, the discussion really should be more about polishing that
contribution and making sure it provides a robust solution to this
feature than trying to postpone or find reasons to put this off.

I've gone on record as stating that annotations within docblocks are
sufficient, and would rather see native support for parsing docblocks
for annotations than introducing a new syntax. Others have stated the
same. I'd like to see why a new syntax is considered "necessary", and
why native support for docblock annotations is not considered a
reasonable path.

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

14 years ago by Sebastian Bergmann — view source

unread

Am 10.05.2011 17:57, schrieb Matthew Weier O'Phinney:

Just because developers are using annotations does not necessarily mean
we need a new syntax.

Exactly the point I tried to make earlier -- just more to the point.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

14 years ago by Drak — view source

unread

Annotations cannot be considered bloat because are being used
increasingly everywhere that is a clear indication that they are
required as part of the PHP core as much as many of the Spl classes.
It should be clear by now that the PHP community really do want
annotations.

Can you back this up, please?

Just because developers are using annotations does not necessarily mean
we need a new syntax.

Sure - I just revisited my browser history today. I turned up at least
dozen annotation driver implementations (including 3 separate PHP C
implementations!) just with a casual google search.

Google Searches

Lots of pages specifically about "PHP annotations" (9,470):
http://www.google.com/search?hl=en&q="php+annotations";
"PHP Annotations" + patch (5,000)
http://www.google.com/search?hl=en&q="php+annotations"+patch
PHP annotations (1.8 million)
http://www.google.com/search?q=php+annotations - you can see lots and
lots of chatter about PHP annotations.

C patches for PHP

http://labs.adoy.net/php-annotations.php (source:
https://github.com/adoy/PHP-Annotations)
http://code.google.com/p/addendum/
https://github.com/marcelog/AnoForPHP
Guilherme Blanco's of course

PHP based annotation drivers

https://github.com/schmittjoh/annotations
https://github.com/jubianchi/PHPAnnotations
https://github.com/oes/pia
http://sourceforge.net/projects/phpannotations/
https://github.com/veritech/Annotations (for CakePHP)
https://github.com/domain51/Domain51_Tool_Annotation
https://github.com/doomspork/sleepy
PHPUnit :-P
Doctrine and so on...
... and these are just projects which have written annotation drivers
found during a quick search.

There is clearly a lot of interest from PHP userland in annotations,
evidenced that annotations have been being used for years already,
most notably by PHPUnit from so long ago. As frameworks adopt
annotations the use of annotations will escalate more and more and
it's already happening since many people use PHP frameworks: people
using the frameworks inevitably use the technology in the framework.
Also logically, people would not be writing drivers if there was not a
demand for it. I feel like I am stating the obvious :)

If PHP accept the patch (in it's current or a modified form) it should
be feature complete. There is no point neutering a perfectly good
feature at it's inception. Whether it's in the docblock, or as
Guilherme's designed in the code, annotations should accept more than
key=>value.

Drak

PS - sorry to say this but from the other thread, all this talk of
ecosystems is quite strange and full of FUD. The PHP eco-system
depends on PHP and exists only because of PHP, not the other way
round. If PHP adds a new syntax or new functions, the IDEs have to
support it - it's only logical or they will lose users to another
product which does support PHP properly and in a timely manner. IDE
vendors provide a solution for people who need a PHP IDE so it only
goes to reason surely? Given their scale and userbase I cant see
Beans and Eclipse PDT ignoring new syntax any time soon nor any of the
commercial IDEs like Zend Studio or phpStorm. If they managed with
namespace support I don't see why this would be any different. I feel
like I'm stating the obvious.

14 years ago by Christopher Jones — view source

unread

PS - sorry to say this but from the other thread, all this talk of
ecosystems is quite strange and full of FUD. The PHP eco-system
depends on PHP and exists only because of PHP, not the other way
round. If PHP adds a new syntax or new functions, the IDEs have to
support it - it's only logical or they will lose users to another
product which does support PHP properly and in a timely manner. IDE
vendors provide a solution for people who need a PHP IDE so it only
goes to reason surely? Given their scale and userbase I cant see
Beans and Eclipse PDT ignoring new syntax any time soon nor any of the
commercial IDEs like Zend Studio or phpStorm. If they managed with
namespace support I don't see why this would be any different. I feel
like I'm stating the obvious.

From a very narrow technical point of view it may appear obvious but
it would lead to a fun paradox that a language feature "for the
community" could get designed without thinking about all the users &
uses.

--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/

14 years ago by Lester Caine — view source

unread

guilhermeblanco@gmail.com wrote:

What I thought it could be changed is:

Allow PHP to support it natively and also take advantage of opcode cache

Make API cleaner

Guilherme you still also have to explain WHY we need this. I have a perfectly
functional documentation and hinting setup working from docblock entries in
several years worth of code. Rewriting all of that would have to have some
reason, and working with two systems in parallel does not make sense. My current
method of working is well supported in phpeclipse while your new offering will
require some major work in phpeclipse and other tools simply to access it? More
work for other open source developers who again probably don't need it. So as
far as I am concerned I need to be persuaded why this code needs to be IN the
core code when I for one can't see any reason to use it. Just because COMPILED
languages have it is not a reason to load an interpreted language with it.
Adding it as a removable extension might make more sense to me, just as much of
the less used code can be disabled if we want. And I was coding in C/C++ long
before I switched TO PHP to get away from the problems of using compiled
languages for dynamic web based systems.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi Lester,

I updated the RFC. I may have missed one thing or two, but overall
idea and how code behave is there.
This question is answered on wiki RFC. =)

Here is the direct link: https://wiki.php.net/rfc/annotations

Regards,

guilhermeblanco@gmail.com wrote:

What I thought it could be changed is:

Allow PHP to support it natively and also take advantage of opcode cache

Make API cleaner

Guilherme you still also have to explain WHY we need this. I have a
perfectly functional documentation and hinting setup working from docblock
entries in several years worth of code. Rewriting all of that would have to
have some reason, and working with two systems in parallel does not make
sense. My current method of working is well supported in phpeclipse while
your new offering will require some major work in phpeclipse and other tools
simply to access it? More work for other open source developers who again
probably don't need it. So as far as I am concerned I need to be persuaded
why this code needs to be IN the core code when I for one can't see any
reason to use it. Just because COMPILED languages have it is not a reason to
load an interpreted language with it. Adding it as a removable extension
might make more sense to me, just as much of the less used code can be
disabled if we want. And I was coding in C/C++ long before I switched TO PHP
to get away from the problems of using compiled languages for dynamic web
based systems.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--

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

14 years ago by Lester Caine — view source

unread

guilhermeblanco@gmail.com wrote:

Hi Lester,

I updated the RFC. I may have missed one thing or two, but overall
idea and how code behave is there.
This question is answered on wiki RFC. =)

Here is the direct link: https://wiki.php.net/rfc/annotations
But there is nothing there that explains why this is any use where we are not
compiling code ... and are all things we are already doing with comment blocks
... which CAN be stripped to speed up operation once in a production
environment. A compiler simply strips the unnecessary stuff when building the
running code, how do you propose PHP does that ? If I want compiled code then I
can use any number of other languages, PHP simply runs what I have in the file.

Regards,

guilhermeblanco@gmail.com wrote:

What I thought it could be changed is:

Allow PHP to support it natively and also take advantage of opcode cache

Make API cleaner

Guilherme you still also have to explain WHY we need this. I have a
perfectly functional documentation and hinting setup working from docblock
entries in several years worth of code. Rewriting all of that would have to
have some reason, and working with two systems in parallel does not make
sense. My current method of working is well supported in phpeclipse while
your new offering will require some major work in phpeclipse and other tools
simply to access it? More work for other open source developers who again
probably don't need it. So as far as I am concerned I need to be persuaded
why this code needs to be IN the core code when I for one can't see any
reason to use it. Just because COMPILED languages have it is not a reason to
load an interpreted language with it. Adding it as a removable extension
might make more sense to me, just as much of the less used code can be
disabled if we want. And I was coding in C/C++ long before I switched TO PHP
to get away from the problems of using compiled languages for dynamic web
based systems.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi Lester,

What you don't see is that you're against having it because you
already had the effort to built this support.
So answering your question related to use cases, you own codebase is a
good example.

You had to create a parser for docblock because PHP doesn't have
support. And now you're asking me why is it needed because you already
implemented it. It's like chicken and eggs.
You wouldn't need to implement a docblock parser IF PHP already supported it.

Also, you own comments answer you own question. You "compile" your
code for production removing the docblocks (or adding a cache, or
generating a file, etc, whatever you want). What does it prohibit you
from doing the same with native support?

Regards,

guilhermeblanco@gmail.com wrote:

Hi Lester,

I updated the RFC. I may have missed one thing or two, but overall
idea and how code behave is there.
This question is answered on wiki RFC. =)

Here is the direct link: https://wiki.php.net/rfc/annotations

But there is nothing there that explains why this is any use where we are
not compiling code ... and are all things we are already doing with comment
blocks ... which CAN be stripped to speed up operation once in a production
environment. A compiler simply strips the unnecessary stuff when building
the running code, how do you propose PHP does that ? If I want compiled code
then I can use any number of other languages, PHP simply runs what I have in
the file.

Regards,

On Mon, May 9, 2011 at 6:42 PM, Lester Cainelester@lsces.co.uk wrote:

guilhermeblanco@gmail.com wrote:

What I thought it could be changed is:

Allow PHP to support it natively and also take advantage of opcode
cache

Make API cleaner

Guilherme you still also have to explain WHY we need this. I have a
perfectly functional documentation and hinting setup working from
docblock
entries in several years worth of code. Rewriting all of that would have
to
have some reason, and working with two systems in parallel does not make
sense. My current method of working is well supported in phpeclipse while
your new offering will require some major work in phpeclipse and other
tools
simply to access it? More work for other open source developers who again
probably don't need it. So as far as I am concerned I need to be
persuaded
why this code needs to be IN the core code when I for one can't see any
reason to use it. Just because COMPILED languages have it is not a reason
to
load an interpreted language with it. Adding it as a removable extension
might make more sense to me, just as much of the less used code can be
disabled if we want. And I was coding in C/C++ long before I switched TO
PHP
to get away from the problems of using compiled languages for dynamic web
based systems.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--

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

14 years ago by Ferenc Kovacs — view source

unread

guilhermeblanco@gmail.com wrote:

Hi Lester,

I updated the RFC. I may have missed one thing or two, but overall
idea and how code behave is there.
This question is answered on wiki RFC. =)

Here is the direct link: https://wiki.php.net/rfc/annotations

But there is nothing there that explains why this is any use where we are
not compiling code ... and are all things we are already doing with comment
blocks ... which CAN be stripped to speed up operation once in a production
environment. A compiler simply strips the unnecessary stuff when building
the running code, how do you propose PHP does that ? If I want compiled code
then I can use any number of other languages, PHP simply runs what I have in
the file.

what do you miss? the general introduction of the annotations or the
implementation specific details of the proposed rfc?
obviously the parser doesn't strip the annotations, because the annotation
isn't comment.
this is why it isn't interchangeble with the docblock that you mention.
if you don't need that kind of information, then you shouldn't use
annotation in your code.
and ffs stop trolling, I tried to ignore your arrogant emails on this topic,
but I couldn't.
please read back the last couple of your message, maybe not I'm the only one
who is offended by your tone.
thanks.

Tyrael

14 years ago by Stas Malyshev — view source

unread

Hi!

I updated the RFC. I may have missed one thing or two, but overall
idea and how code behave is there.
This question is answered on wiki RFC. =)

Here is the direct link: https://wiki.php.net/rfc/annotations

Some questions I didn't find the answers in the RFC:

When the annotation objects are instantiated?
What is permissible in the arguments of annotation - e.g. can I put
any expression there?
What <Foo(<Bar>)> actually means and how it is supposed to be parsed?
What happens if ctor for annotation has error/exception?
Are there any limitations on classes that can be used as annotations?
Do we need any special support for bytecode caches?

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

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi Stas,

Hi!

I updated the RFC. I may have missed one thing or two, but overall
idea and how code behave is there.
This question is answered on wiki RFC. =)

Here is the direct link: https://wiki.php.net/rfc/annotations

Some questions I didn't find the answers in the RFC:

When the annotation objects are instantiated?

Objects are only instantiated when requested (getAnnotations() or
getAnnotation())

What is permissible in the arguments of annotation - e.g. can I put any
expression there?

You are allowed to use any scalar value + array + any object that
implements ReflectionAnnotation interface.

What <Foo(<Bar>)> actually means and how it is supposed to be parsed?

It would instantiate a class Bar and would pass it as an instance of
Foo that is also being created when doing getAnnotations() or
getAnnotation('Foo')

What happens if ctor for annotation has error/exception?

There're error support just like PHP has. Here is a sample:

Fatal error: Uncaught exception 'Exception' with message 'Fooooo' in
/src/php-src/trunk/ok.php:6
Stack trace:
#0 [internal function]: simpleannotation->__construct()
#1 /src/php-src/trunk/ok.php(15):
ReflectionClass->getAnnotation('simpleannotatio...')
#2 {main}
thrown in /src/php-src/trunk/ok.php on line 6

Code:

class SimpleAnnotation implements ReflectionAnnotation {
public function __construct()
{
throw new Exception('Fooooo');
}
}

<SimpleAnnotation> class Foo { }

$r = new ReflectionClass('Foo');
var_dump($r->getAnnotation('SimpleAnnotation'));

Are there any limitations on classes that can be used as annotations?

As I said, only classes that implement ReflectionAnnotation are
allowed to be used. It gives errors if you attempt to do something
invalid.
Here is the error you get if you attempt to use a non-declared annotation:

class Foo implements ReflectionAnnotation {
public function __construct($bar)
{}
}

class Bar {}

<Foo(<Bar>)>
class FooBar {
}

$r = new ReflectionClass('FooBar');
var_dump($r->getAnnotations());

Fatal error: ReflectionClass::getAnnotations(): 'Bar' must implement
'ReflectionAnnotation' to act as an annotation in - on line 15

Do we need any special support for bytecode caches?

Yes. Every structure which can be annotated now will have a new member
in their C structure which is annotations, this structure is populated
at compile time and store all the metadata information. So if you have
an opcode cache the compilation will not occur, so the annotations
will be NULL. That's why the opcode cache will have to store the
annotations, so that it can be retrieved every time.

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

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

14 years ago by Stas Malyshev — view source

unread

Hi!

Objects are only instantiated when requested (getAnnotations() or
getAnnotation())

So how this happens - does the class store the text of the annotation?
Or expressions in the call are evaluated and stored, but the object is
not instantiated?
What if I call getAnnotation() repeatedly - are they re-instantiated or
stored somewhere, and if so - where?

What is permissible in the arguments of annotation - e.g. can I put any
expression there?

You are allowed to use any scalar value + array + any object that
implements ReflectionAnnotation interface.

By scalar value you mean constant value? Are constants allowed?

What<Foo(<Bar>)> actually means and how it is supposed to be parsed?

It would instantiate a class Bar and would pass it as an instance of
Foo that is also being created when doing getAnnotations() or
getAnnotation('Foo')

So when exactly Bar is instantiated - when getAnnotations() is called?

Do we need any special support for bytecode caches?

Yes. Every structure which can be annotated now will have a new member
in their C structure which is annotations, this structure is populated
at compile time and store all the metadata information. So if you have
an opcode cache the compilation will not occur, so the annotations
will be NULL. That's why the opcode cache will have to store the
annotations, so that it can be retrieved every time.

This then should be added to the proposal.

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

14 years ago by Pierrick Charron — view source

unread

Hi,

First, the actual patch is working but Implementation and behavior may
change following all comments. This is still a work in progress and all
comments/contributions from everybody are welcome :)

That said :

Hi!

Objects are only instantiated when requested (getAnnotations() or

getAnnotation())

So how this happens - does the class store the text of the annotation? Or
expressions in the call are evaluated and stored, but the object is not
instantiated?
What if I call getAnnotation() repeatedly - are they re-instantiated or
stored somewhere, and if so - where?

Annotations are stored in a HashTable of zend_annotation.

struct _zend_annotation {
char *annotation_name;
unsigned int aname_len;

HashTable *values;
zval instance; / This is not permanent */
};

Once you call the getAnnotation method the reflection class will evaluate
all expressions and instantiate the object. A reference of the object is
then saved in the instance member of the structure. However, we have a plan
to move this instance somewhere else like in a EG.

What is permissible in the arguments of annotation - e.g. can I put any

expression there?

You are allowed to use any scalar value + array + any object that
implements ReflectionAnnotation interface.

By scalar value you mean constant value? Are constants allowed?

Yes constants are allowed. Otherwise you can use annotation and static
scalar (same thing as default value of class properties for example)

What<Foo(<Bar>)> actually means and how it is supposed to be parsed?

It would instantiate a class Bar and would pass it as an instance of
Foo that is also being created when doing getAnnotations() or
getAnnotation('Foo')

So when exactly Bar is instantiated - when getAnnotations() is called?

When you call getAnnotation() the reflection method will instantiate Bar,
and then instantiate the Foo object using the Bar instance as first
parameter of the constructor.

Do we need any special support for bytecode caches?

Yes. Every structure which can be annotated now will have a new member
in their C structure which is annotations, this structure is populated
at compile time and store all the metadata information. So if you have
an opcode cache the compilation will not occur, so the annotations
will be NULL. That's why the opcode cache will have to store the
annotations, so that it can be retrieved every time.

This then should be added to the proposal.

We will add it

Thanks for your feedback.

Pierrick

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

14 years ago by Stas Malyshev — view source

unread

Hi!

I'm not bitching against do and don't dos... I'm bitching about
ignored feature that are not even discussed.

I think annotations were discussed very extensively. But I totally can
see how one particular aspect could slip through. In this case it is
right to remind people about it and restart the discussion - by stating
what exactly was missed and what new was out there that in your opinion
didn't get enough attention.

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

14 years ago by Lars Schultz — view source

unread

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.

14 years ago by guilhermeblanco@gmail.com — view source

unread

Hi Larz,

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.

--

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

14 years ago by Lester Caine — view source

unread

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

14 years ago by dukeofgaming — view source

unread

On Wed, May 11, 2011 at 2:59 AM, Lars Schultz lars.schultz@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.

14 years ago by Lars Schultz — view source

unread

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.

Please let's not bitch about lazy users not learning C to implement THEIR missing feature. (Was Re: 5.4 again)

Richard.

Richard.

These issues were mentioned before - were they fixed? The RFC also does not clarify where the code contained in annotations is run and how it would play with bytecode caches.

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Google Searches

C patches for PHP

PHP based annotation drivers

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

These issues were mentioned before - were they fixed?
The RFC also does not clarify where the code contained in annotations is
run and how it would play with bytecode caches.

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL