Re: Extensions to traits
| From: | Stefan Marr | Date: | Thu, 06 Jan 2011 23:18:35 +0000 |
| Subject: | Re: Extensions to traits | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-51237@lists.php.net to get a copy of this message | ||
Hi Ben:
Here the second part, on your extension proposal.
On 02 Jan 2011, at 13:16, Ben Schmidt wrote:
> Extension
> - - - - -
>
> I suggest these two problems can be simply solved by introducing two
> additional uses of the trait keyword: as a scoping keyword and an access
> specifier.
>
> As a scoping keyword, it would be used analogously to self. Method calls
> such as $this->print() could be replaced with trait::print() when the
> programmer desires to ensure that their trait method, and only their
> trait method, is called--when there is no intention that overriding
> should be possible. It would only be able to be used in a trait, and
> could only be used to reference methods or properties defined in the
> same trait, using their original name.
>
> As an access specifier, it would be used instead of public, private,
> etc. in trait definitions, to mean that the member (data or method) can
> and can only be accessed using the mechanism above (trait::).
Ok, that would actually get us around all the meta-programming problems.
When you say that the 'trait'-access modifier always requires the access via a specific
keyword (trait::) then mangling the name should be possible.
On the other hand, what would iterating over the object properties show?
Multiple properties with the same name, like with inherited private properties I suppose?
And an occurrence of trait:: would mean, do a $this-> but mangle the name first with the
trait's name the original definition was in. Should be possible, but would certainly impact the
Zend Engine a bit more than what we have now.
Certainly an interesting approach.
Has someone else an opinion on that?
>
>
> Overriding
> ==========
>
> Limitation
> ----------
>
> At present, the overriding semantics of traits are that a method defined
> in a class proper overrides a method defined in a used trait which in
> turn overrides a method defined in an ancestor class.
Bye the way, where comes that terminology from: class proper? We are talking about the body of a
class, right?
Well, but I will stop here, and try to cover the rest in the next mail...
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525