Am 16.09.2010 18:02, schrieb Matthew Weier O'Phinney:
>
>> 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.
>
For me the mistake is that annotation classes must be defined with their
FQN or you must create an alias for the namespace. This alias must be
registered before using this annotations. Every framework I use uses its
own rules for defining annotatations, registering annotation namespaces
and so on. For me this is impractical. Registering the namespace with
the out of the box PHP use statement is for me the better way.
I thought this was clear from my comparison.
>> 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 -- itwer
> ist den dir auf den schlips getreten
> 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.
This isn't what I meant with different syntax. Different syntax for me is:
[Annotation([1, 2, 3])]
@Annotation({1, 2, 3})
%Annotation(array(1, 2, 3))
Have fun, using annotations from different frameworks for one and the
same method, property or class.
>> 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.
>
If an annotation throws an exception because of syntax errors you get an
stack trace. So it should not be a problem to localize this error.
In this example the annotations doesn't throw any exceptions.
$user = new User;
$user->id = 'only integers are allowed';
$validator = new Validator();
$results = $validator->validate($user);
The result contains a constraint violation message. For more you can
look at the Hibernate Validator page.
http://www.hibernate.org/subprojects/validator.html
>> 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.
I meant that this developers who using this frameworks must not learn
different syntaxes but rather one.
> Using existing
> docblocks and adding an annotations parser to it would be using existing
> syntax.
>
- How would you comment out an annotation in a doc block?
- How would you define annotations with namespaces?
- Parsing of annotations is slow. When using caching every framework
that I use implements other caching rules for its annotations.
There are many more reasons mentioned in all the mails.
You may excuse me because I am not an native English speaker so it can
be be the case the one or the other formulation isn't correct.
Greetings,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
