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
On Thu, Aug 26, 2010 at 12:43 AM, Ilia Alshanetsky wrote:
> Stas,
>
> Having E_FORTY_TWO would be super-useful ;-)
>
>
offtopic:
shouldn't be that E_ANSWER_TO_LIFE_UNIVERSE_AND_EVERYTHING?
maybe we should set E_ALL for 42 too. :)
-1 for E_DEVELOPMENT E_PRODUCTION E_EVERYTHING
+1 for the E_NONE
+
On Thu, Aug 26, 2010 at 12:43 AM, Ilia Alshanetsky wrote:
> Stas,
>
> Having E_FORTY_TWO would be super-useful ;-)
FOURTY! Only to annoy all English teachers out there :)
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing
Stas,
Having E_FORTY_TWO would be super-useful ;-)
On Tue, Aug 24, 2010 at 1:47 PM, Stas Malyshev wrote:
> Hi!
>
>> Rhetorical question: Why do we need constants when the values never
>> change? :)
>
> You seriously don't know why one needs constants or don't see a difference
> between constant
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
On Wed, Aug 25, 2010 at 7:47 PM, Tyler Lawson wrote:
> In short, I don't want to see "error_reporting(E_NONE | E_ERROR);" in
> anybody's PHP code. Even if it is harmless.
What I don't want to see is "E_NONE" as a string [1].
Also people, why does every little detail like a goddamn constant
pote
David Zülke wrote:
>
> That's because you're doing it wrong:
>
> error_reporting(E_NONE | E_ERROR);
>
> - David
>
>
You're correct that I did it wrong and I apologize. Your example is how
it would be properly written out and it would work the way the
programmer expects it.
My point was tha
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
2010/8/24 Adam Harvey :
> Kalle also suggested another constant within that request to provide a
> symbolic version of error_reporting = -1, so there's a second patch in that
> report to add an E_EVERYTHING constant which acts as E_ALL once did: it
> turns on all error reporting.
On a personal
On 25.08.2010, at 15:51, Tyler Lawson wrote:
> Sebastian Bergmann wrote:
>
>> So nobody will use E_DEVELOPMENT or E_NONE or whatever. We can only add
>> options to PHP that offer choices to developers. If they do not use
>> them ... what can we do?
>>
>
> As a regular user of PHP, I like the id
Sebastian Bergmann wrote:
> So nobody will use E_DEVELOPMENT or E_NONE or whatever. We can only add
> options to PHP that offer choices to developers. If they do not use
> them ... what can we do?
>
As a regular user of PHP, I like the idea of E_DEVELOPMENT and
E_PRODUCTION. They're clear an
On Wed, Aug 25, 2010 at 3:44 PM, Sebastian Bergmann wrote:
> On 08/25/2010 03:38 PM, Pierre Joye wrote:
>> Nobody uses the recommendation in the two php.inis.
>
> So nobody will use E_DEVELOPMENT or E_NONE or whatever. We can only add
> options to PHP that offer choices to developers. If they do
On 08/25/2010 03:38 PM, Pierre Joye wrote:
> Nobody uses the recommendation in the two php.inis.
So nobody will use E_DEVELOPMENT or E_NONE or whatever. We can only add
options to PHP that offer choices to developers. If they do not use
them ... what can we do?
--
Sebastian Bergmann
On Wed, Aug 25, 2010 at 3:34 PM, Sebastian Bergmann wrote:
> On 08/25/2010 03:07 PM, Derick Rethans wrote:
>> Don't we already have this with the default two php.inis we have in some
>> form?
>
> Yes, we do. And I, for one, also do not see the point for new E_*
> constants.
Nobody uses the reco
On 08/25/2010 03:07 PM, Derick Rethans wrote:
> Don't we already have this with the default two php.inis we have in some
> form?
Yes, we do. And I, for one, also do not see the point for new E_*
constants.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://seb
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
On Tue, 24 Aug 2010, Adam Harvey wrote:
> I'd be happy enough with E_DEVELOPMENT instead of E_EVERYTHING. The
> point is that everything should be on — we should be encouraging
> developers to fix up E_STRICT notices as well as the usual array of
> things E_ALL shows.
Don't we already have this w
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
29 matches
Mail list logo
