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