On Mon, 13 Sep 2010 19:20:31 +0100, Stas Malyshev <smalys...@sugarcrm.com>
wrote:
The proposed annotations are basically object instances that are
returned when you call getAnnotations. There are no itemized lists of
rules. I
don't see how this is complex.
They aren't just object instances, since they also have separate syntax
to create them - unlike the syntax to create all other objects. And it
wouldn't be a problem if it would be something trivial - like just class
name - but we have here whole new syntax complete with nesting, named
parameters, validation logic and what not.
I share some of these concerns. But a new feature like this would always
require new syntax.
The best (in the sense of "most similar to what we have today") syntax I
can think of is to define annotations exactly the same way was you'd
define arrays, but replace "array" with the annotation name (plus a
prefix). I think this looks like PHP:
%JoinTable(
"name" => "users_phonenumbers",
"joinColumns" => array(
%JoinColumn("name" => "user_id", "referencedColumnName" => "id")
),
"inverseJoinColumns" => array(
%JoinColumn("name" => "phonenumber_id", "referencedColumnName" =>
"id", unique => true)
)
)
The named parameters could be replaced by directly setting the fields
(basically like the ReflectionAnnotation::__construct already does) and
marking the constructor final. If validation logic is really necessary, we
could add a validate() method to ReflectionAnnotation (with an empty
default implementation) that subclasses could override to provide their
validation logic.
Off-topic stuff follows:
- LSB. Can you explain from the top of your head when when the called
scope is reset or not (e.g. with parent::, self::, className::, possibly
in non-static contexts) in a function call? I can't.
It's not that hard. Keywords forward, classnames don't.
Fair enough, though I find surprising that "parent" forwards. But you'll
find that most users don't see LSB as a "scope that is forwarded" but
instead as some kind of inheritance mechanism. It also exposed the odd
behavior of keeping subclass copies of static properties in the same
reference set as the parent by default, which causes confusion.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
