Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51072
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 81.20.134.149 cause and error)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <201012132027.59678.larry@garfieldtech.com>
Date: Sat, 18 Dec 2010 16:29:16 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <76C593EE-BCCA-4BBD-B625-B6AE9340B20C@stefan-marr.de>
References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de> <AANLkTi=dz1pu7B+1k-xAbCRPmFx24J=27ABaWLRuPwqK@mail.gmail.com> <D9ED43A9-833E-4644-9DFC-DE89CF83656F@stefan-marr.de> <201012132027.59678.larry@garfieldtech.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Traits and Properties
From: php@stefan-marr.de (Stefan Marr)

Hi Larry:

On 16 Dec 2010, at 23:31, Larry Garfield wrote:

> I am fine with this approach, with 2 caveats:
>=20
> - If you actually do want to make two traits use the same property, it =
looks like the answer here is "Either have no property and demand the =
existence of an accessor that returns by reference, or you can't write =
E_NOTICE-safe code".  Is that true?
Yes, that is the tradeoff, perhaps the notice could be restricted be =
shown in strict-mode only.

The manual says the following about E_STRICT, so it seems to fit, but I =
am not sure about the usual usage of E_STRICT throughout the engine.

Manual:
> Note:
> In PHP 5 a new error level E_STRICT is available. As E_STRICT is not =
included within E_ALL you have to explicitly enable this kind of error =
level. Enabling E_STRICT during development has some benefits. STRICT =
messages will help you to use the latest and greatest suggested method =
of coding, for example warn you about using deprecated functions.



> - When the visibility collides, should we be folding to the most =
restrictive or least restrictive?  I'm not sure myself; I'm more =
interested in your reasoning for going for most-restrictive.
So, in general, I think, there is no 'right thing' to do here, because =
the definitions seem to be incompatible but that is only decidable at =
the application-level.

There is another, related, edge-case in the test case below.
In the test we have different initial values for the properties, which =
makes it 'obvious' that they are incompatible.
Thus, in that case I would argue for a E_COMPILE_ERROR instead of a =
notice.

The reason to use the stricter modifier is, well, arbitrary.

At least I do not find an argument for either way that completely =
convinces me.
At the moment, the main reason is that 'public' can be considered to be =
the default visibility modifier.
Based on the semantics of 'var' and dynamic properties.
Thus, private tends to imply that an additional constraint was =
consciously applied to the property, which should be preserved.
Well, but as I said, thats kind of arbitrary and if you look at the =
inheritance rules and try to reason from the view of clients with =
respect to the external interface, then going with public as the chosen =
modifier also starts to sound reasonable...


=20


--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 =3D "foo";
}

trait THello2 {
  public $hello =3D "bar";
}

class TraitsTest {
	use THello1;
	use THello2;
	public function getHello() {
	    return $this->hello;
	}
}

$t =3D new TraitsTest;
?>
--EXPECTF--=09
Fatal error: Conflicting definitions for property TraitsTest::$hello =
provided by THello1, THello2 in %s on line %d




Best regards
Stefan


--=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