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

- Thread: https://externals.io/message/52149
- Original archive: https://news-web.php.net/php.internals/52149
- Started by Richard Quadling on 2011-05-09T16:13:42+00:00
- Messages: 84
- Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/52149.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #52149 — Richard Quadling — 2011-05-09T16:13:42+00:00

URL: https://externals.io/message/52149#52149

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

---

## #52165 — guilhermeblanco@gmail.com — 2011-05-09T17:32:19+00:00

URL: https://externals.io/message/52149#52165 · In reply to: #52149

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:
> > […]
>
> 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

---

## #52167 — Rasmus Lerdorf — 2011-05-09T17:38:57+00:00

URL: https://externals.io/message/52149#52167 · In reply to: #52165

> 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

---

## #52170 — guilhermeblanco@gmail.com — 2011-05-09T17:48:17+00:00

URL: https://externals.io/message/52149#52170 · In reply to: #52167

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,


> 
> > […]
>
> 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

---

## #52172 — Rasmus Lerdorf — 2011-05-09T17:53:58+00:00

URL: https://externals.io/message/52149#52172 · In reply to: #52170

> 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

---

## #52173 — guilhermeblanco@gmail.com — 2011-05-09T18:07:52+00:00

URL: https://externals.io/message/52149#52173 · In reply to: #52172

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


> 
> > […]
>
> 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

---

## #52174 — Stas Malyshev — 2011-05-09T18:13:38+00:00

URL: https://externals.io/message/52149#52174 · In reply to: #52165

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

---

## #52176 — Stas Malyshev — 2011-05-09T18:35:45+00:00

URL: https://externals.io/message/52149#52176 · In reply to: #52173

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

---

## #52178 — Ferenc Kovacs — 2011-05-09T18:40:09+00:00

URL: https://externals.io/message/52149#52178 · In reply to: #52176

On Mon, May 9, 2011 at 8:35 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
>  If possible, could you look at the patch and give me high level ideas
> > […]
>
> 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

---

## #52179 — guilhermeblanco@gmail.com — 2011-05-09T18:53:12+00:00

URL: https://externals.io/message/52149#52179 · In reply to: #52176

Hi Stas,

Comments inline.


> Hi!
>
> > […]
>
> 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

---

## #52181 — Lester Caine — 2011-05-09T21:42:22+00:00

URL: https://externals.io/message/52149#52181 · In reply to: #52173

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

---

## #52185 — guilhermeblanco@gmail.com — 2011-05-09T23:27:02+00:00

URL: https://externals.io/message/52149#52185 · In reply to: #52181

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:
> > […]
>
> 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

---

## #52187 — Lester Caine — 2011-05-10T00:25:38+00:00

URL: https://externals.io/message/52149#52187 · In reply to: #52185

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,
>
> 
> > […]

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

---

## #52188 — Stas Malyshev — 2011-05-10T00:35:40+00:00

URL: https://externals.io/message/52149#52188 · In reply to: #52185

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

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

---

## #52189 — guilhermeblanco@gmail.com — 2011-05-10T00:35:49+00:00

URL: https://externals.io/message/52149#52189 · In reply to: #52187

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:
> > […]
>
> 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.
>
> > […]
>
> --
> 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

---

## #52190 — Ferenc Kovacs — 2011-05-10T00:36:17+00:00

URL: https://externals.io/message/52149#52190 · In reply to: #52187

> guilhermeblanco@gmail.com wrote:
>
> > […]
> 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

---

## #52191 — guilhermeblanco@gmail.com — 2011-05-10T00:55:42+00:00

URL: https://externals.io/message/52149#52191 · In reply to: #52188

Hi Stas,


> Hi!
>
> > […]
>
> Some questions I didn't find the answers in the RFC:
> 1. When the annotation objects are instantiated?

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

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

> 3. 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')

> 4. 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'));

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


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

---

## #52192 — Stas Malyshev — 2011-05-10T01:23:08+00:00

URL: https://externals.io/message/52149#52192 · In reply to: #52191

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?

> > […]
>
> 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?

> > […]
>
> 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?

> > […]
>
> 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

---

## #52193 — Pierrick Charron — 2011-05-10T03:04:07+00:00

URL: https://externals.io/message/52149#52193 · In reply to: #52192

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
> > […]
>
> 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.


>
>
>  2. What is permissible in the arguments of annotation - e.g. can I put any
> > […]
>
> 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)


>
>
>  3. What<Foo(<Bar>)>  actually means and how it is supposed to be parsed?
> > […]
>
> 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.


>
>
>  6. Do we need any special support for bytecode caches?
> > […]
>
> 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

---

## #52194 — Mike Willbanks — 2011-05-10T03:42:45+00:00

URL: https://externals.io/message/52149#52194 · In reply to: #52179

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

---

## #52195 — Pierrick Charron — 2011-05-10T03:50:46+00:00

URL: https://externals.io/message/52149#52195 · In reply to: #52194

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

---

## #52196 — Drak — 2011-05-10T04:10:06+00:00

URL: https://externals.io/message/52149#52196 · In reply to: #52194

> 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

---

## #52197 — Lester Caine — 2011-05-10T05:46:10+00:00

URL: https://externals.io/message/52149#52197 · In reply to: #52196

Drak wrote:
> > […]
> Annotations cannot be considered bloat because are being used increasingly
> everywhere that is a clear indication that they are required as part of the
> PHP core as much as many of the Spl classes.  It should be clear by now that
> the PHP community really do want annotations.  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

---

## #52198 — Pascal COURTOIS — 2011-05-10T06:07:21+00:00

URL: https://externals.io/message/52149#52198 · In reply to: #52197

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

---

## #52199 — Chad Fulton — 2011-05-10T07:01:30+00:00

URL: https://externals.io/message/52149#52199 · In reply to: #52197

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

---

Next page: https://externals.io/message/52149.md?page=2