Replies to a) and b) below:
Andi Gutmans wrote:
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.
If you read the stateful traits paper Stefan linked to, you can see a
precedent for how this has been implemented. By default the properties
are private to the scope of the trait. The client class can also make an
alias to the property and have access to this property through this
private alias property. The client class can also merge multiple
properties into one common properties.
The problem with this is during flattening. When there is a conflicting
property, all references have to be "alpha-renamed" in all the trait
methods. This is a more costly operation as compared to the flattening
of stateless traits. This may not be reason enough not to include it,
but it should definitely be a consideration.
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
Let me use a quote on aliasing from this paper
<http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf>: "The
new name is used to obtain access to a method that would otherwise be
unreachable because it has been overridden." The point of aliasing is to
give the client class a way to call the old method after it has been
overridden.
Generally, if two traits have the same method names, you would want to
alias both of them, override the method, and use the aliases to compose
the overridden method. The other option is to just choose one of the
trait's method implementations and exclude all others.
And if you are talking about making the old method that is aliased into
a method that is private to just that trait, flattening would then
require some kind of "alpha-rename" for even stateless traits in some cases.
--
"Joshua Thompson" <[EMAIL PROTECTED]>
<http://www.schmalls.com>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
