Re: Extensions to traits

Hi again, Stefan, Continuing the conversation. On 7/01/11 10:18 AM, Stefan Marr wrote:

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?

Well, I hadn't thought about it before. :-) But yes, I think that makes perfect sense.

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.

One complication I hadn't thought of before is whether it should be possible to access trait:: methods and properties in different objects. And if it should be, what syntax to use. $that->trait::method() seems somewhat ugly to me. That would also suggest we should use $this->trait::method() for the same-object case.

Certainly an interesting approach. Has someone else an opinion on that?

I think actually this is the most important part of my proposal, so if it could be accepted, I would be very pleased. Obviously it does need a bit more thought and discussion yet, though.

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?

Yes. 'Class proper' = 'class itself'. We seem to use 'proper' in English as an adjective after a noun with a Latin-like sense of 'own/itself'. I guess we probably got it from French, and surprisingly it hasn't died out. Cheers, Ben.