Re: Extensions to traits

From: 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

« previous php.internals (#51237) next »