Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51104
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.59.228 cause and error)
To: internals@lists.php.net
Date: Mon, 20 Dec 2010 20:24:09 -0600
User-Agent: KMail/1.13.5 (Linux/2.6.34.7-0.5-desktop; KDE/4.4.4; x86_64; ; )
References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de> <4D0F7E99.8050705@garfieldtech.com> <764A364B-173B-401B-83FA-A61D45BE99CB@stefan-marr.de>
In-Reply-To: <764A364B-173B-401B-83FA-A61D45BE99CB@stefan-marr.de>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <201012202024.10153.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Traits and Properties
From: larry@garfieldtech.com (Larry Garfield)

On Monday, December 20, 2010 5:21:08 pm Stefan Marr wrote:
> Hi Larry:
> 
> On 20 Dec 2010, at 17:04, larry@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