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