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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
