Re: RFC: Traits for PHP

Hi, Andi Gutmans schrieb:

I haven't thought this through completely but I think we may want to consider a different model from supporting "removing" and "aliasing" of functions. I think this can create a lot of complications especially in larger works and it'll be write-once code and hard for a newcomer to the code to really understand. I think the main reason to support removing/aliasing of functions is in order to avoid conflicts with other Traits/Class methods. Maybe what we can do is to have only "aliasing" but what it would do is to create a public function with the new name and convert the old function into a private function. Sounds a bit like what had been proposed in this paper: http://www.iam.unibe.ch/~scg/Archive/Papers/Duca07b-FreezableTrait.pdf

The first point, yes exclusion and aliasing are only meant to handle conflicts, and should be used only in this context. Yeah you can break the trait with it, but you did it explicitly, think this should be made clear a bit more in the discussion about "breaking interfaces". Nobody would request unset to be removed from the function set even though you can do this: $a = new A(); unset($a); $a->foo(); //damn... It is "almost" like excluding a method from a trait and be worried about the trait breaks. Isn't it? :)

Benefits: - Keeps the old code from running predictably without breaking dependencies. Well, in the code I've read so far, exclusion has been used to cog/dovetail to traits which supplement each other very well.

- Possibly even allowing some form of "is-a" relationship to continue to be valid (and therefore the interface discussion may even be resolved; at least to a certain level). In the case I faced an is-a relationship (i.e. working instanceof operator) would have been nice. Hm, I would prefer to not add the type notion to traits. They are only units of reuse, not types IMHO.

I need to put a bit more thought into this but it's an initial attempt to provide an additional point of view which may actually give some more structure to the proposal while still delivering the benefits of this idea.

I think if this kind of idea could be fully baked it would solve the problems I have had in the past possibly without the more dangerous renaming/removing

of functions. I have not looked into feasibility of this idea yet. Think user-changeable location of composed methods is quite possible, but for the cost of complexity. (Have a look at the paper for the complete idea of trait-local/freezed methods.)

Kind Regards Stefan