Hi Pierrick, Guilherme
2010/8/25 Pierrick Charron :
> I'm here to propose a new feature in PHP: Annotations.
> A patch is already available with 54 tests for the moment[2].
>
> I worked together with Guilherme Blanco to make this support happen in
> a fresh PHP SVN trunk checkout.
> Please review,
Through aliasing via use is a better approach, I forgot about it.
But this still need to be implemented. Currently it doesn't handle
aliased namespaces too.
Related to instantiation per demand, it is true that can be optimized
to only instantiate things once.
As off array X objects, no matter whi
Test, sorry for the noise.
On Aug 26 13:56:09, Etienne Kneuss wrote:
>
> - "Benjamin Eberlei" wrote:
>
> > That is true, arrays dont allow for aliasing of any kind if
> > annotations
> > have different meaning in different frameworks.
> > With arrays you can at least use the one annotation
On Thu, 26 Aug 2010 13:56:09 +0200 (CEST), Etienne Kneuss
wrote:
>
> I don't understand why aliasing of class names suddenly becomes an
issue,
> we now have namespaces which allow aliases.
>
> use NS\To\MyAnnotation as MyAnnot;
>
> [MyAnnot]
> class Foo {
>
> }
>
> there is no need to have th
Oh this is an elegant solution, didnt even cross my mind.
For larger sets of annotations this would require lots of use statements
though,
but it makes the aliasing very explicit indeed.
On Thu, 26 Aug 2010 13:56:09 +0200 (CEST), Etienne Kneuss
wrote:
> - "Benjamin Eberlei" wrote:
- "Benjamin Eberlei" wrote:
> That is true, arrays dont allow for aliasing of any kind if
> annotations
> have different meaning in different frameworks.
> With arrays you can at least use the one annotation for different
> purposes
> as long as these purposes don't define the same keys.
>
That is true, arrays dont allow for aliasing of any kind if annotations
have different meaning in different frameworks.
With arrays you can at least use the one annotation for different purposes
as long as these purposes don't define the same keys.
With Objects however you always need aliasi
On Thu, 26 Aug 2010 11:17:33 +0200, Benjamin Eberlei
wrote:
> Hey,
>
> 3.
> Ok that point may be relevant, but there is also a semantically nice and
> simple solution:
>
> array('JoinTable' => array(
> 'name' => 'users_phonenumbers',
> 'joinColumns' => array(
> 0 => array('JoinCo
Hey,
1. Annotations on Annotation Classes is an overcomplication. You could
very well get rid of this feature and NOT do inheritance, leaving
it to PHP userland implementations to handle inheritance of annotations
correctly (inheritance of annotations only make sense on Class/Methods
anyway
Hi Stas :
I see many points to use classes instead of just arrays :
1) If you just use array, it is not possible to annotate an annotation
to do something like [Inherited] and other eventual annotations for
annotation.
As Guilherme mentioned in one of his previous mail, we are thinking
about addi
Hi!
When you call getAnnotation('foo') it will just call
Foo::__construct(array('value' => 'bar', 'baz' => 'hello world'));
So there is no overhead on the execution time even if you have
annotations in your code.
But there's a lot of overhead if you use them - as objects are created
anew ea
The constructor is called when you call the getAnnotations() or
getAnnotation() methods.
The current implementation basically do :
- At compile time you store all the data in a HashTable structure like
any other structure, class, method, properties...
- On execution time it does nothing unless you
- "Etienne Kneuss" wrote:
> - "Guilherme Blanco" wrote:
>
> > @Christian:
> >
> > Placing items on constructor may be valid at first glance, but it
> > would break class inheritance (constructor prototype).
> > So, that's why this idea was dropped.
> >
> > @Etienne:
> >
> > How woul
- "Pierrick Charron" wrote:
> 2010/8/25 Etienne Kneuss :
> >
> > - "Guilherme Blanco" wrote:
> >
> >> Hi Etiene,
> >>
> >>
> >> AliasedName is not implemented yet, but I added in RFC as one of
> the
> >> first enhancements to be done.
> >> The purpose of it is to reduce the over-typing
- "Guilherme Blanco" wrote:
> @Christian:
>
> Placing items on constructor may be valid at first glance, but it
> would break class inheritance (constructor prototype).
> So, that's why this idea was dropped.
>
> @Etienne:
>
> How would it work with nested Annotations?
>
> %Foo(%Bar(type
2010/8/25 Etienne Kneuss :
>
> - "Guilherme Blanco" wrote:
>
>> Hi Etiene,
>>
>>
>> AliasedName is not implemented yet, but I added in RFC as one of the
>> first enhancements to be done.
>> The purpose of it is to reduce the over-typing needed to instantiate
>> namespaced classes.
>>
>> Here i
@Christian:
Placing items on constructor may be valid at first glance, but it
would break class inheritance (constructor prototype).
So, that's why this idea was dropped.
@Etienne:
How would it work with nested Annotations?
%Foo(%Bar(type=%Woo))
If you consider just PHP after it, the correct w
- "Guilherme Blanco" wrote:
> Hi Etiene,
>
>
> AliasedName is not implemented yet, but I added in RFC as one of the
> first enhancements to be done.
> The purpose of it is to reduce the over-typing needed to instantiate
> namespaced classes.
>
> Here is the first idea:
>
> ReflectionAnno
Hi,
I love this RFC. But I have a view questions.
1.
> Since php does not support named parameter the __construct is called
> with an array as parameter
> [Foo("bar", baz="baz)]
> will call __construct(array("value" => "bar", "baz" => "baz));
>
I am a absolute C noob but I have implemented name
Hi Etiene,
AliasedName is not implemented yet, but I added in RFC as one of the
first enhancements to be done.
The purpose of it is to reduce the over-typing needed to instantiate
namespaced classes.
Here is the first idea:
ReflectionAnnotation::addNamespaceAlias('Doctrine', 'Doctrine\ORM\Mappi
The inheritance support of annotations only affects classes am I right?
I would get rid of this stuff completely, its rather complicated and
simplify to only returning only the annotations specified on the
reflected class.
As I said before, no-one hinders you from implementing arbitrary complex
us
Hi Etienne,
2010/8/25 Etienne Kneuss :
> On Aug 25 8:56:53, Pierrick Charron wrote:
>> Hello PHP Internals!
>>
>> Recently a RFC was included on the PHP Wiki[1].
>> I know there've been a lot of buzz related to PHP 5.4, but this is not
>> the subject of this email.
>>
>> I'm here to propose a new
One of the advantage of classes vs array is that you have to create
the class and define its structure and behaviour before using it.
For example you cannot do with Array something like the [Inherited] annotation :
[Inherited]
class SampleAnnotation extends ReflectionAnnotation {}
How could you d
Hi Pierrick,
Awesome RFC! :) I think this is a really useful addition on many levels.
We had a chat about this yesterday, i just wanted to throw it into the
discussion here again:
I think a solution where "->getAnnotations()" returns only an array of the
annotations data is simpler to u
Hello PHP Internals!
Recently a RFC was included on the PHP Wiki[1].
I know there've been a lot of buzz related to PHP 5.4, but this is not
the subject of this email.
I'm here to propose a new feature in PHP: Annotations.
A patch is already available with 54 tests for the moment[2].
I worked tog
25 matches
Mail list logo
