On Sat Oct 22 04:38 AM, Nathan Nobbe wrote: > Hi folks, > > With a 5.4 release right around the corner I'd like a moment of your > time to reconsider this issue [1]. > > Just curious why it died on the table if several folks saw value in > it, including Stephan who I gather is the primary architect of traits. > > The dispute regarding the feature was the merit of a 'compile time' > check vs placing the burden on the developer to ensure all methods in > a trait are provided by the class in which it is used. In an earlier > conversation about traits Stefan said this: > > "Yes, Traits are meant to be compile-time only, they are not used to > introduce typing relationships." > > Which makes me even more comfortable about the merit of another > compile time check. As I argued in the original thread, the feature > is merely an embellishment atop the already supported use of the > 'abstract'
I think it's up to Stefan's experience & wisdom. To really cover all use cases, it might be worth looking into using a require{} block as a way to list the requirements for the composing class (and get rid of the abstract syntax). e.g. trait Bar { require { function foo(); private $_prop; implements Iterator; } function moveNext() { $this->foo(); $this->_prop = 'hello'; $this->next(); } } class Foo implements Iterator { use Bar; //ok function foo() {} private $_prop; function next() .... iterator methods } class FooFailure { use Bar; // E_FATAL: composing requirements not met (implements Iterator, function foo()) private $_prop; } Traits is already an advanced concept, a conservative approach would be to remove the 'abstract' check and see how people end up using traits. If there's enough use cases (not foo/bar examples) out there that need compile time checks, add the proper syntax for it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php