Re: Annotations in PHP7
| From: | guilhermeblanco@gmail.com | Date: | Wed, 18 Feb 2015 18:28:25 +0000 |
| Subject: | Re: Annotations in PHP7 | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-83103@lists.php.net to get a copy of this message | ||
Hi Dmitry,
> Are you (and Doctrine team) interested in this annotation idea?
I'd say that Benjamin nailed in our possible usage:
<orm(new Entity("foo"))>
class Foo {
}
Now I do feel we need to elaborate some sort of named parameters. Doctrine
tries to simplify a lot developer's life by using consistency in default
mapping and only if the user wants to override default behavior he needs to
override a given parameter. This means in a case where you're mapping a
JoinColumn (
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/JoinColumn.php
),
you may only want to specify the onDelete="CASCADE" operation instead of
name, referencedColumnName and many other parameters.
Trying to map this in your default parameter passing, we'd have something
like:
<orm(
[
new OneToOne("Address"),
new JoinColumn(default, default, default, default, "CASCADE")
]
)>
public $address;
As I said, named parameters make a lot of sense when mapping defaults.
Now by looking at this syntax, I still think we're closer to a simple array
implementation (ReflectionClass::getMetadata(string $name)) and having
something like:
<[
"orm" => [
new OneToOne("Address"),
new JoinColumn(default, default, default, default, "CASCADE")
]
]>
public $address;
PS: We haven't even started on talking about overrides yet... =\
Regards,
On Wed, Feb 18, 2015 at 12:04 PM, Dmitry Stogov <dmitry@zend.com> wrote:
>
>
> On Wed, Feb 18, 2015 at 6:14 PM, François Laupretre <francois@php.net>
> wrote:
>
>> Hi Dmitry,
>>
>>
>>
>> Right. That’s what I got from your last reply. But my question was about
>> another post where you are talking about ‘compile time evaluation’ of
>> expressions, which is different from the bare key/value storage I
>> understood first, and poses the problem of compile time evaluation scope
>> (which also exists at runtime).
>>
>>
>>
>> If you just store the expression as a bare string or AST without
>> evaluating it, that’s fine and, even, much better from a performance point
>> of view. I just want to make it clear for me and everyone that there will
>> be no possibility of compile time evaluation. That’s all.
>>
>
> right.
>
> Again, sorry to insist ;).
>>
>
> no problem.
>
> Thaks. Dmitry.
>
>
>>
>>
>> François
>>
>>
>>
>> I answer the last time.
>> Annotations is just a key value storage, where value may be AST for php
>> expression.
>>
>> Your may do with it whatever you like (traverse, evaluate, compile), but
>> PHP core itself is not going to do anything.
>>
>> Thanks. Dmitry.
>>
>
>
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada