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

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

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

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

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

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:

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');
}
}

$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