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
