Hi Larry:
On 16 Dec 2010, at 23:31, Larry Garfield wrote:
> I am fine with this approach, with 2 caveats:
>
> - 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...
--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 = "foo";
}
trait THello2 {
public $hello = "bar";
}
class TraitsTest {
use THello1;
use THello2;
public function getHello() {
return $this->hello;
}
}
$t = new TraitsTest;
?>
--EXPECTF--
Fatal error: Conflicting definitions for property TraitsTest::$hello provided
by THello1, THello2 in %s on line %d
Best regards
Stefan
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
