Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51055
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 85.88.12.247 cause and error)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
In-Reply-To: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de>
Date: Thu, 16 Dec 2010 16:25:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <581ACCE6-71A4-444F-A226-8D87E1B43EEF@stefan-marr.de>
References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de>
To: "internals@lists.php.net Development" <internals@lists.php.net>
Subject: Re: [PHP-DEV] Traits and Properties
From: php@stefan-marr.de (Stefan Marr)

Hi:

=46rom my point of view the right thing to do with regard to properties =
is defined in the test cases below.

The rational behind providing this semantics is based on the fact that =
PHP allows to define properties dynamically anyway, so there is no way =
around properties.
However, there should be a way that a developer can notice that the code =
might not behave as expected in the composed class.

It is true that behavior needs state to operate on, however, accessors =
are a common pattern and fully supported by traits. Furthermore, traits =
are not supposed to replace classes, and when a trait does more than =
just providing code that is to be easily reused, then the designed =
should ask the question whether that is not actually a class, which then =
provides the necessary guarantees to enforce the invariances the code =
expects.

Thus, I would like to keep traits as a lightweight concept for code =
reuse.

Best regards
Stefan

--TEST--
Conflicting properties should result in a notice.
Property use is discorage for traits that are supposed to enable =
maintainable
code reuse. Accessor methods are the language supported idiom for this.
--FILE--
<?php
error_reporting(E_ALL);

trait THello1 {
  public $foo;
}

trait THello2 {
  private $foo;
}

class TraitsTest {
	use THello1;
	use THello2;
}

var_dump(property_exists('TraitsTest', 'foo'));
?>
--EXPECTF--=09
Notice: Trait THello1 and THello2 define the same property in the =
composition of TraitsTest. This might be incompatible, to improve =
maintainability consider using accessor methods instead. Class was =
composed in %s on line %d.

bool(true)




--TEST--
Non-conflicting properties should work just fine.
--FILE--
<?php
error_reporting(E_ALL);

trait THello1 {
  public $hello =3D "hello";
}

trait THello2 {
  private $world =3D "World!";
}

class TraitsTest {
	use THello1;
	use THello2;
	function test() {
	    echo $this->hello . ' ' . $this->world;
	}
}

var_dump(property_exists('TraitsTest', 'hello'));
var_dump(property_exists('TraitsTest', 'world'));

$t =3D new TraitsTest;
$t->test();
?>
--EXPECTF--=09
bool(true)
bool(true)

hello World!


--TEST--
Conflicting properties with different visibility modifiers should be =
merged
to the most restrictive modifier.
--FILE--
<?php
error_reporting(E_ALL);

trait THello1 {
  public $hello;
}

trait THello2 {
  private $hello;
}

class TraitsTest {
	use THello1;
	use THello2;
}

$t =3D new TraitsTest;
$t->hello =3D "foo";
?>
--EXPECTF--=09
Fatal error: Cannot access private property TraitsTest::$foo in %s on =
line %d

On 11 Dec 2010, at 17:47, Stefan Marr wrote:

> Hi:
>=20
> Traits do not provide any special provisioning for handling =
properties, especially, there is no language solution for handling =
colliding property names.
> The current solution/idiom for handling state safely in a trait is to =
use either abstract set/get methods or an abstract get that returns a =
reference to the property in the class.
>=20
> However, at the moment it is possible to define properties in a trait:
>=20
> trait Foo {
> private $a;
> public  $foo;
> }
>=20
> For the moment, that information is completely ignored, thus:
>=20
> class Bar {
> use Foo;
> }
> property_exists('Bar', 'a') =3D=3D=3D false
>=20
>=20
> Well, and that is a rather inconsistent status-quo.
>=20
> I would like to have that fixed in one or another way.
>=20
> One possibility would be to forbid property definition in a trait =
altogether.
> That reduces a bit the possibility to have wrong expectations about =
properties, however, the dynamic property creation is still possible.
>=20
> Another way would be to merge the properties in the composing class.
> The question here would be how to treat visibility modifiers: how to =
merge public and private, should it result in public, or private?
> And, to discorage users to go this way, should there be a STRICT =
notice? Options here are a notice whenever a property is defined in a =
trait, or whenever properties are silently merged.
>=20
>=20
> Comments very welcome.
>=20
> Thanks
> Stefan
>=20
> --=20
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
>=20
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

--=20
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525