Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51450
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain openmv.com from 64.15.152.204 cause and error)
To: "'Ben Schmidt'" <mail_ben_schmidt@yahoo.com.au>,
	<internals@lists.php.net>
References: <4D206CA4.6060004@yahoo.com.au> <005f01cbadc9$1172d080$34587180$@com> <4D284B8B.5040408@yahoo.com.au> <4D537DE1.2010309@yahoo.com.au> <36AB1B1C-1C92-475D-84C7-D0B0DB8FE462@roshambo.org> <4D541F8A.4050502@yahoo.com.au>
In-Reply-To: <4D541F8A.4050502@yahoo.com.au>
Date: Tue, 15 Feb 2011 10:02:48 -0500
Message-ID: <007201cbcd21$696da7c0$3c48f740$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcvJR58kgzySrR3qR+OJEvdS1v4quwD1haHg
Content-Language: en-ca
Subject: RE: [PHP-DEV] Extensions to traits
From: jbondc@openmv.com ("Jonathan Bond-Caron")

On Thu Feb 10 12:25 PM, Ben Schmidt wrote:
> 
> http://wiki.php.net/rfc/traitsmodifications
> 

Some thoughts:

a) Class method conflict with trait

Class implementation always wins I feel is the right way to think about
traits.

But 'abstract' already has special meaning, so maybe a keyword like 'final'
could also do something special.

b) Support for 'non-breakable traits'

 - Add trait-local scope

Really like the idea and how this could make traits less fragile. 
e.g.
trait Foo {
  trait $bar;       
  public $bar;
}

Could change the syntax to:
trait Foo {
  var $bar = 'visibleByTrait';     // variable private to the trait --
zend_mangle_property_name('#Foo {NULL} bar')
  public $bar = 'visibleByClass';  // variable public to the class it gets
composed in
}

class Test {
  use Foo;
}

$t = new Test;
echo $t->bar; // 'visibleByClass'

Seems like it could allow traits to have their own independent state
(private properties), internally ~ zend_mangle_property_name('#' trait name
{NULL} prop name).

Small note: is there a plan to drop the T_VAR token?

Any objections, concerns, more thoughts on the concept?

c)  Extend 'use' syntax

Didn't quite understand, will read again.
Have you thought about how this could affect the reflection api and
documentation?