Hi!
As traits are fixed compositions in contrast to the dynamic concept mixin it's in the hands of the developer to let replace() do the right thing [tm] as the developer has all the information he needs to decide what replace() needs to do when writing code.
replace() does the right thing - it uses add() and delete(). The problem here is that current proposal allows any user to yank the ground from under the feet of the trait API creator and replace various bits of the class with any other functionality without any regard for the interdependency between them, so either each function in the traits should be completely self-reliant and never use other functions - which prevents one from create complete non-trivial APIs - or every rename should be painfully verified with original trait developer or against the actual source code, breaking the abstraction. Both don't seem too practical to me.
-- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
