RE: [PHP-DEV] RFC: Traits for PHP

Hi Stefan, Thanks for writing such a good proposal. In general I think traits is a very interesting idea. I can think of a few cases in my life as a programmer where it could have helped me out. I think some comments re: the syntax/naming are good ones but I prefer not to get into naming in this email. I believe we can brainstorm re: naming when we figure out exactly what we want to do. I do support though finding a way which is simple for non-English speakers but not too simple like Perl:) Thinking back at the times when something like this would have been useful to me I think there are a couple of main points I'd like to brainstorm about: a) I think Traits should be able to act as a self-contained behavior which can always be expected to work. For example if I want a Counter behavior I would like that not to depend on the properties in the containing class. While I don't think we should enable public nor protected properties in Traits I think allowing for private properties in Traits would come in very handy. It also is no problem when it comes to mangling as we can use the Trait name. class Trait { private $counter = 0; function getNextSerialNumber() { return $this->counter++; } } I strongly recommend not to support protected/public and not to even get into the discussion of dealing with conflicts of such properties. But I think private is very useful. b) 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. Benefits: - Keeps the old code from running predictably without breaking dependencies. - 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. 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. Anyway, good ideas and thanks for the very professional way you have brought this idea to the community. Let's try and nail down the behavior and then we can have the harder naming discussion :) Just saying harder because I've always considered naming the hardest part in software engineering... Andi