Re: svn: /php/php-src/trunk/Zend/tests/traits/ error_001.phpt error_002.phpt error_003.phpt error_004.phpt error_005.phpt error_006.phpt
error_007.phpt error_008.phpt error_009.phpt
| From: | Felipe Pena | Date: | Fri, 07 May 2010 14:16:08 +0000 |
| Subject: | Re: svn: /php/php-src/trunk/Zend/tests/traits/ error_001.phpt error_002.phpt error_003.phpt error_004.phpt error_005.phpt error_006.phpt error_007.phpt error_008.phpt error_009.phpt |
||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-48250@lists.php.net to get a copy of this message | ||
2010/5/7 Felipe Pena <felipensp@gmail.com>
> 2010/5/6 Stefan Marr <php@stefan-marr.de>
>
>>
>
> Hi Felipe:
>>
>> Hope you don't mind that I post it on the list, think the discussion
>> should be properly archived.
>>
>>
> No problem..., open source, open discussion. :-)
>
>
>> On 06 May 2010, at 18:30, Felipe Pena wrote:
>>
>> > Hello,
>> >
>> > 2010/5/6 Stefan Marr <php@stefan-marr.de>
>> > Hi Felipe:
>> >
>> > On 05 May 2010, at 22:00, Felipe Pena wrote:
>> > > One question... Looking at the grammar, I got a doubt... Is actually
>> intended to allow constructions like 'trait foo extends ...' and 'trait foo
>> implements ...' ? (I can't see an example like that on the RFC)
>> >
>> > The idea is that traits form its own hierarchy of composition, and since
>> they can be composed from traits itself, it should not be necessary, to
>> allow inheritance.
>> >
>> > So, no, extends and implements should not be allowed.
>> > The idea of allowing interfaces was rejected in the first big
>> discussion.
>> > Interfaces belong to classes, and traits are solely meant to provide
>> implementation.
>> > Since you can exclude methods, it does not fit well with the notion of
>> interfaces.
>> >
>> > There are a number of things which are not quite clear in the grammar at
>> the moment.
>> > My idea was that I just reuse the class grammar, and add exceptions for
>> the situations which are not allowed.
>> > Mostly to avoid duplicating the relevant grammar parts.
>> >
>> > Do you think it would be better to do it the other way around, and use a
>> dedicated grammar for traits?
>> >
>> > We could use a dedicated grammar or make the properly checks in the
>> compiler. Both solutions looks good for me.
>> >
>> > I got a new question for you... Shouldn't we don't allow the
>> implementation of magic methods and constructors in Traits?
>>
>> Hm, well, don't know, but I do not really see a reason to disallow magic
>> methods.
>>
>> There are definitely use-case for something like __toString.
>> Constructors are a complicated topic on its own. But in general, the
>> initialization part might also be reusable.
>>
>> So, what would be your argument why they might be 'harmful'?
>>
>>
> I am not against it, I was just asking because both topics (magic methods &
> constructors) aren't currently working on my tests.
>
JFYI: I've committed a fix and tests related to this issue.
--
Regards,
Felipe Pena