Hello all.
In trying to follow the annotations threads currently running, I've
come to realise just how little I understand a LOT of what I read
here.
But, then again, I don't need to, so hurrah for me. I try to follow,
but, #fail most of the time.
One thing that did come to mind is if we ignore all the issues and
complexities of actually implementing annotations, are annotations
useful to a significant number of userland developers. On the surface,
(and this is probably where I'm going wrong), it would seem to only
really be of use to framework developers, and whilst there are at
least 2.5 frameworks per developer, the vast majority of userland
developers are not framework developers. So are they useful enough to
be included at all, or is it just serving a small minority and
distracting the other core developers?
Is this something that can just be an extension with its own evolution?
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
hi,
Is this something that can just be an extension with its own evolution?
Unless the PHP parser engine can be extended via normal or zend
extensions, no, it can't. And pretty useless to have annotations
outside the core...
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
Unless the PHP parser engine can be extended via normal or zend
extensions, no, it can't. And pretty useless to have annotations
outside the core...
I disagree - it would be very useful if we could do that. I.e. if we
could associate data with classes, functions, etc. without actually
changing the code. Unfortunately, we don't have it yet. Some languages -
like Python - have those as first-class objects, so you can just put
stuff there. We don't have it, though we have Reflection - so we might
use it instead.
Then, the question of syntax arises. Basically, if we had method in
ReflectionClass like this:
static function addAnnotation($class, Annotation $a) {
self::$annotations[$class][] = $a;
}
and we could have some useful syntax to call it implicitly - say, on
class creation - that would be it. However, we have here two problems
that we can't solve yet: 1) extending Reflection (maybe can be done in
userspace) 2) adding syntax (probably can't be done in userspace unless
somebody thinks of a clever way to do it).
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
userspace) 2) adding syntax (probably can't be done in userspace unless
somebody thinks of a clever way to do it).
I've thought of it, and I guess I'll give it a go, I could make this a
proposal if it makes sense to.
The idea is to make the Zend Engine aware that annotations exist without
the worry of what the syntax is. Syntax can then be deferred to the
consumer. How to accomplish? Well:
- Zend Engine should have a new token T_ANNOTATION that is demarcated by
an opening [ and a closing ] (with necessary escaping for ] along the
way if need be) that should exists before PHP declarations (func,
property, method, class, const, etc). Multiple annotations per
declaration are ok.
- Add new methods to Reflection APIs: getAnnotations() and
getParsedAnnotations().
-
Add a new extension called annotation responsible for registering and
implementing annotation parsers:annotation_register_parser($name, AnnotationParser $p|$validcallback);
** and an interface for AnnotationParser
interface AnnotationParser
{
public function tokenize($string); // array of tokens
public function execute(array $tokens);
}(if AnnotationParser is used, Reflection can "byte-code" cache the
tokens from tokenize())
-
Add real implementations of syntax:
// class to handle proposed doctrine syntax, similar to c#
class AnnotationAttributeParser { /** ... */ }// perhaps a simple key value based parser
class AnnotationKeyValueParser { /** .. */ }// perhaps a PHP include parser
class AnnotationPHPIncludeParser { /** .. */ } -
Usage:
annotation_register_parser('doctrine', new AnnotationAttributeParser);
// callbacks can be used as wel
annotation_register_parser('zfservice', array('MyClass',
'myCallbackMethod'));
How would this work?
When Reflection<>::getParsedAnnotations() is called, it will check
for a registered key in the annotation (of one does not exist, exception
is thrown).. code would look like this:
[doctrine:ClassMap('foo' => 'bar', 'rest of c# nested syntax')]
public $foo;
This also allows other frameworks to propose and use their own syntax
that makes the most sense to them:
[symfonyDi:arg1=Foo,arg2=Bar]
public function setStuff(Foo $arg1, Bar $arg2) {...}
or
[zendservice:param1=string;return=int]
public function doFooForWebService() { /* .. */ return $someInt; }
you could even use url based annotations:
annotation_register_parser('wordpress', 'parse_str');
in code:
[wordpress:first=value&arr[]=foo+bar&arr[]=baz]
function wp_plugin_handle_something() {}
Since annotation formats and knowing annotations might be required are a
requirement of the framework/system the consumer has adopted, that
framework can specify the format of the string used inside the annotation.
Also, multiple annotations can be attached to various declarations,
hence the getParsedAnnotations(), perhaps getParsedAnnotation($index)
would be valid as well.
thoughts?
-ralph
On Fri, 17 Sep 2010 10:02:10 +0100, Richard Quadling
rquadling@gmail.com wrote:
Hello all.
In trying to follow the annotations threads currently running, I've
come to realise just how little I understand a LOT of what I read
here.But, then again, I don't need to, so hurrah for me. I try to follow,
but, #fail most of the time.One thing that did come to mind is if we ignore all the issues and
complexities of actually implementing annotations, are annotations
useful to a significant number of userland developers. On the surface,
(and this is probably where I'm going wrong), it would seem to only
really be of use to framework developers, and whilst there are at
least 2.5 frameworks per developer, the vast majority of userland
developers are not framework developers. So are they useful enough to
be included at all, or is it just serving a small minority and
distracting the other core developers?
This isn't right. At a first glance, yes it looks that only framework
developers can have a benefit from annotations in the core. But the
annotations extending the API of a framework so that all developers
which using this frameworks have a great benefit of them.
Lets take as dependency injection as example. If the framework
implements this concept than the user of the framework make the usage of
this. Or the bean validation framework. This is only for the framework
users.
Is this something that can just be an extension with its own evolution?
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
On Fri, Sep 17, 2010 at 6:28 AM, Christian Kaps
christian.kaps@mohiva.com wrote:
On Fri, 17 Sep 2010 10:02:10 +0100, Richard Quadling
rquadling@gmail.com wrote:One thing that did come to mind is if we ignore all the issues and
complexities of actually implementing annotations, are annotations
useful to a significant number of userland developers. On the surface,
(and this is probably where I'm going wrong), it would seem to only
really be of use to framework developers, and whilst there are at
least 2.5 frameworks per developer, the vast majority of userland
developers are not framework developers.This isn't right. At a first glance, yes it looks that only framework
developers can have a benefit from annotations in the core. But the
annotations extending the API of a framework so that all developers
which using this frameworks have a great benefit of them.Lets take as dependency injection as example. If the framework
implements this concept than the user of the framework make the usage of
this. Or the bean validation framework. This is only for the framework
users.
I agree with Christian here, something that is "for framework
developers" benefits all of the userland users that use that
framework.
So we are not looking at the minority of framework developers but at
the majority of framework users.
So i think the point of "is there use for annotations" is mute, yes
there is and we don;t see more examples cause we never had it.
How often did anyone suggest creating a state machine in the ZF
Controller before we had goto available? once it became available we
started finding uses for it.
So i'm pretty sure one Annotations exist, more and more people will
get familiar with it and find new ways to use it in their mindset.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
On Fri, Sep 17, 2010 at 6:28 AM, Christian Kaps
christian.kaps@mohiva.com wrote:On Fri, 17 Sep 2010 10:02:10 +0100, Richard Quadling
rquadling@gmail.com wrote:One thing that did come to mind is if we ignore all the issues and
complexities of actually implementing annotations, are annotations
useful to a significant number of userland developers. On the surface,
(and this is probably where I'm going wrong), it would seem to only
really be of use to framework developers, and whilst there are at
least 2.5 frameworks per developer, the vast majority of userland
developers are not framework developers.This isn't right. At a first glance, yes it looks that only framework
developers can have a benefit from annotations in the core. But the
annotations extending the API of a framework so that all developers
which using this frameworks have a great benefit of them.Lets take as dependency injection as example. If the framework
implements this concept than the user of the framework make the usage of
this. Or the bean validation framework. This is only for the framework
users.I agree with Christian here, something that is "for framework
developers" benefits all of the userland users that use that
framework.
So we are not looking at the minority of framework developers but at
the majority of framework users.So i think the point of "is there use for annotations" is mute, yes
there is and we don;t see more examples cause we never had it.
How often did anyone suggest creating a state machine in the ZF
Controller before we had goto available? once it became available we
started finding uses for it.So i'm pretty sure one Annotations exist, more and more people will
get familiar with it and find new ways to use it in their mindset.
Thanks for that.
So, where can I read something about annotations aimed at what must be
painfully obvious someone without all the skills.
How would I use annotations? What problems that I don't know I have do
they solve for me?
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
Hi Richard,
Comments inline
On Fri, Sep 17, 2010 at 6:28 AM, Christian Kaps
christian.kaps@mohiva.com wrote:On Fri, 17 Sep 2010 10:02:10 +0100, Richard Quadling
rquadling@gmail.com wrote:One thing that did come to mind is if we ignore all the issues and
complexities of actually implementing annotations, are annotations
useful to a significant number of userland developers. On the surface,
(and this is probably where I'm going wrong), it would seem to only
really be of use to framework developers, and whilst there are at
least 2.5 frameworks per developer, the vast majority of userland
developers are not framework developers.This isn't right. At a first glance, yes it looks that only framework
developers can have a benefit from annotations in the core. But the
annotations extending the API of a framework so that all developers
which using this frameworks have a great benefit of them.Lets take as dependency injection as example. If the framework
implements this concept than the user of the framework make the usage of
this. Or the bean validation framework. This is only for the framework
users.I agree with Christian here, something that is "for framework
developers" benefits all of the userland users that use that
framework.
So we are not looking at the minority of framework developers but at
the majority of framework users.So i think the point of "is there use for annotations" is mute, yes
there is and we don;t see more examples cause we never had it.
How often did anyone suggest creating a state machine in the ZF
Controller before we had goto available? once it became available we
started finding uses for it.So i'm pretty sure one Annotations exist, more and more people will
get familiar with it and find new ways to use it in their mindset.Thanks for that.
So, where can I read something about annotations aimed at what must be
painfully obvious someone without all the skills.
Unfortunately, my primary source of knowledge contains dummy
information, which is Wikipedia.
So, for an average explanation of usage, you can check the Annotations
RFC[1] or what is described in Java Annotations[2] (although I'm in
favor entirely of it).
How would I use annotations? What problems that I don't know I have do
they solve for me?
In PHP exclusively, I can point you the JSR-303 (Bean Validation) that
is implemented in Symfony 2.
Here is the source:
http://github.com/symfony/symfony/tree/master/src/Symfony/Component/Validator/
Usage example: http://docs.symfony-reloaded.org/guides/validator.html
Another good example is to map your persistence data into your
Entities. Doctrine 2 implements this and I think that way you can
compare easily with the PHP code alternative. I'd like to ask you to
compate the same Entity mapped through Annotations emulator and using
raw PHP code:
CmsUser using Annotations:
http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/Models/CMS/CmsUser.php
CmsUser using PHP code:
http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Mapping/php/Doctrine.Tests.ORM.Mapping.User.php
I can't be more explicit how beneficial it is with Annotations support.
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
Another good example is to map your persistence data into your
Entities. Doctrine 2 implements this and I think that way you can
compare easily with the PHP code alternative. I'd like to ask you to
compate the same Entity mapped through Annotations emulator and using
raw PHP code:
CmsUser using Annotations:
http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/
M
odels/CMS/CmsUser.php
CmsUser using PHP code:
http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/
O RM/Mapping/php/Doctrine.Tests.ORM.Mapping.User.php
You're basically bundling (M: Model, data & configuration, C: Control, business logic / code) into a single class while the MVC pattern is all about separating M,V and C.
What's wrong with a simple configuration file? Caching the parsed config in shared memory?
One important flaw rarely mentioned with annotations config: your code now depends on framework X to read the annotations instead of a simple configuration file (.xml, .ini., ...)
Sorry if I might sound harsh but configuration through annotations is terrible.
You'll find many .net or java developers that agree, I'd say it's 50-50 if not more 70-30.
Does this discussion still belong in internals? We could argue about this for months, java astronauts don't even agree how annotations are useful:
http://www.javaworld.com/community/node/2613
Inline response:
Another good example is to map your persistence data into your
Entities. Doctrine 2 implements this and I think that way you can
compare easily with the PHP code alternative. I'd like to ask you to
compate the same Entity mapped through Annotations emulator and using
raw PHP code:
CmsUser using Annotations:
http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/
M
odels/CMS/CmsUser.php
CmsUser using PHP code:
http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/
O RM/Mapping/php/Doctrine.Tests.ORM.Mapping.User.phpYou're basically bundling (M: Model, data& configuration, C: Control, business logic / code) into a single class while the MVC pattern is all about separating M,V and C.
Jonathan, I think you are misinterpreting this code. There is no
Controller (Front controller, or parameter mapping from $_POST or $_GET)
nor View responsibilities (echo) here. These are all Model concerns:
how is data persisted, how is it mapped to the persistence layer, how
are entities created and how are their dependencies injected, etc.
By using doctrine, you are adopting & subscribing to Doctrines
philosophy of how tool based modeling should work. The code doesnt run
without doctrine in the mix anyway (you'd have their entity manager in
play at all times). How they (the Doctrine project) decide to manage
mappings is up to them, and you'd be free to either consume their ORM
framework, or not. It is both a development time and production time tool.
What's wrong with a simple configuration file? Caching the parsed config in shared memory?
There is nothing wrong with that, but that is only a single approach.
Alot of times, developers want a close relationship between the metadata
and the code it is about. That means not in separate files, but inside
the same file. This is why projects like *Hibernate are so popular in
enterprise software. No one wants to develop an ORM, they just want a
way to persist their objects.. and a little penalty in performance is a
sound trade-off.
One important flaw rarely mentioned with annotations config: your code now depends on framework X to read the annotations instead of a simple configuration file (.xml, .ini., ...)
Doctrine, Symphony DI, even ZF.. and include to that the non PHP
solutions.. none of these are frameworks you can adpot in less than 5
minutes. It takes some investment of time to understand their
philosophy and also decide how it best fits into your personal code toolkit.
That means that you'd have understood how said framework plans and does
use these annotations.
Sorry if I might sound harsh but configuration through annotations is terrible.
You'll find many .net or java developers that agree, I'd say it's 50-50 if not more 70-30.Does this discussion still belong in internals? We could argue about this for months, java astronauts don't even agree how annotations are useful:
http://www.javaworld.com/community/node/2613
Arguments like this will always exist. But that's less the point. The
point is is that there are many developers that exists that have taken
the time to adopt a persistence framework like *Hibernate, and no one
can argue that they do not get their job done, and annotations have
certainly helped them get there and create maintainable code.
-ralph
Inline response:
Another good example is to map your persistence data into your
Entities. Doctrine 2 implements this and I think that way you can
compare easily with the PHP code alternative. I'd like to ask you
to compate the same Entity mapped through Annotations emulator and
using
raw PHP code:
CmsUser using Annotations:http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests
/
M
odels/CMS/CmsUser.php
CmsUser using PHP code:http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests
/ O RM/Mapping/php/Doctrine.Tests.ORM.Mapping.User.php
You're basically bundling (M: Model, data& configuration, C:
Control, business logic / code) into a single class while the MVC
pattern is all about separating M,V and C.Jonathan, I think you are misinterpreting this code. There is no
Controller (Front controller, or parameter mapping from $_POST or
$_GET) nor View responsibilities (echo) here. These are all Model
concerns:
I'm not talking about "web mvc" and mapping urls to controllers.
There's another pattern where you have a controller (php class) and a data model (sql schema, .xsd, ...)
Problem statement: How do I map class properties to a given data model (sql schema, .xsd, ...)?
Some believe (strong opinions) that using annotations to do this is not a "good example", though abundant usage in java.
It would better serve the discussion if "good" and "bad" was left out and if annotations were presented and promoted in a more neutral way.
If we take a more fun example, how is a swiss army knife useful?
- It can be used to open cans of food.
- It can be used to cut hair.
- It can be used to shave in the morning.
...
I have full faith in the ability of core developers to make their own opinions on how annotations can be useful to the php community at large. There are more things to be considered then technical arguments.
The bigger emerging problem is the complete lack of "formal process" to propose changes to php's syntax:
a) How to write a proposal to be accepted for review
b) How and by who the proposal will be reviewed
c) Who makes the final decision (e.g. executive committee) to approve or reject a proposal.
Going back to annotations, the discussions seems to be bouncing from (a) to (c) while it seems like we are still at (a).
I've been following internals only for the past couple of years and I don't know enough the history but it seems like it would be time to write a document that defines a "formal process" to propose syntax changes (Zend/zend_language_parser.y, ...?)
I'm more than willing to start writing a draft, e.g. a much simplified version of:
http://jcp.org/en/procedures/jcp2
Is this worth a try?