On Monday, December 20, 2010 5:21:08 pm Stefan Marr wrote:
> Hi Larry:
>
> On 20 Dec 2010, at 17:04, la...@garfieldtech.com wrote:
> > Perhaps if both traits use the same variable name, visibility, *and*
> > default value then there is no error?
>
> There is not fatal error, however, currently there is E_STRICT notice.
>
> > I suspect this issue dovetails with the Traits-and-interfaces thread from
> > earlier.
>
> Ehm, not sure what you want to get at.
> The idea of expressing that the composing class needs to satisfy an
> interface, or perhaps inherit from a specific class still seems to have a
> number of valid use cases. However, there was a single strong opinion
> against it, as far as I remember.
I mean, for instance, if you're using an accessor method then you need that
accessor to exist, because you're hard coding its name. If you instead
provide the accessor yourself, the accessor will be hard coded to a variable
name, whether you provide it or not. So either way your trait will die if the
including class doesn't provide some supporting something.
Example:
Trait Foo1 {
function increment() {
// Implicit requirement that a class have a property named foo.
$this->foo++;
}
}
Trait Foo2 {
// Implicit requirement that a class NOT a property named foo.
protected $foo;
function increment() {
$this->foo++;
}
}
Trait Foo3 {
function increment() {
$foo = &$this->getFoo();
$foo++;
}
function &getFoo() {
// Implicit requirement that a class have a property named foo.
return $this->foo;
}
}
Trait Foo4 {
function increment() {
// Implicit requirement that a class have a method named getFoo().
$foo = &$this->getFoo();
$foo++;
}
}
class Test {
use Foo;
}
So one way or another, there is always an implicit requirement placed on the
using class. Implicit requirements suck. :-) If the answer to trait-based
properties is "if it breaks when you do that, don't do that" (which I don't
fully agree with, in part because of how ugly lots of return-by-ref methods
is), then we have to make the methods as easy as possible. Requiring an
interface is one proposed way to do that.
Reading the RFC over again, I actually see that there is support for abstract
methods in a trait. I suppose that serves a similar purpose of causing a
compile-time error (and thus something much more obvious to be fixed), and
becomes becomes a matter of taste to a degree.
I don't believe the RFC mentions how those resolve in case of collision,
though. If two traits define the same abstract method, does that cause a
collision that needs manual resolution or can the using class just define it
once and thereby support both traits?
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
