On 2010-09-15, Christian Kaps <christian.k...@mohiva.com> wrote:
> Am 14.09.2010 22:12, schrieb Stas Malyshev:
> > I think we _already_ have metadata in PHP, albeit done through
> > phpdocs. So the question is kind of moot :) We should see if it's
> > enough for us or we want to add/change/extend it and if so, how.
>
> in my mind there is a big mistake when using annotations in PHPDoc comments.
What is the mistake? You don't explain that anywhere in your reply -- you simply
give code examples of how you feel they should work.
> As example let as use a JSR 303 - Bean Validator like Hibernate
> Validator for PHP.
>
> namespace my\project\models\dto;
>
> class User {
>
> /**
> * @com\jsr303\validator\constraints\NotNull
> * @com\jsr303\validator\constraints\Integer
> */
> public $id;
<snip>
> It is possible to use this type of annotations but it is impracticable.
How is it impractical? What exactly is impractical about it? To be honest, what
you show above (and also in your more "ideal" examples below) leaves me
scratching my head -- if the classnames don't have the word "validator" in them,
I have _zero_ idea what the intent of the annotation is.
> An other problem is that every framework use its one annotation syntax.
> So it makes the framework end user more confusing as using a clear
> unique syntax.
Actually, I see this as a _benefit_ or _feature_ of such an approach -- it
allows developers to define their own annotations, which allows them to create
new approaches. We see this already in docblock annotations -- PHPUnit makes use
of them (@expectedException, @group, etc.). Groups like the Framework Interop
Group can tackle standard use cases.
> I think the PHP way should be as in the next example.
>
> namespace my\project\models\dto;
>
> use com\jsr303\validator\constraints\NotNull;
> use com\jsr303\validator\constraints\Integer;
> use com\jsr303\validator\constraints\Regexp;
> use com\jsr303\validator\constraints\MinLength;
> use com\jsr303\validator\constraints\MaxLength;
> use my\project\validator\constraints\Zipcode;
>
> class User {
>
> [NotNull]
> [Integer]
> public $id;
This is entirely unclear to me. Will it type-cast to integers? will it throw an
exception for null values? I actually don't know what this code will do -- which
brings me to my chief issue so far with this debate: annotations, since they are
meant to be "machine-readable" (that's what all the proponents are saying,
anyways), introduce a huge WTF factor when debugging -- is it the code that
caused an exception? If not, was it an annotation? Which one? what input did it
get? etc.
<snip>
> With this out of the box PHP annotations it makes it possible to create
> powerful frameworks which can used by a great range of developers
> without learning a new syntax for it. Pleas do not argue about thy
> syntax of the annotation because this isn't final.
Um, you're being contradictory here -- you're actually _suggesting_ a brand new
syntax, which leads to the exact opposite of what you assert. Using existing
docblocks and adding an annotations parser to it would be using existing syntax.
--
Matthew Weier O'Phinney
Project Lead | matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
