On 12/20/10 7:53 AM, Matthew Weier O'Phinney wrote:
On 2010-12-19, Stefan Marr<p...@stefan-marr.de>  wrote:
On 19 Dec 2010, at 17:22, Matthew Weier O'Phinney wrote:
Exactly. I wouldn't default to public on conflicts, though -- just with
the highest declared visibility (e.g., if one trait defines as private
and the other as protected, protected wins).
I am currently actually implementing the most restricted proposal: all
differences in the property definition will lead to a fatal error.

The reasoning behind this is, that the semantics of state is not
predictable and all changes in the class/traits hierarchies which are
incompatible should give the developer an immediate feedback, i.e.,
make potentially incompatible code break.  That is not the most
'dynamic' of all possible solutions but seems to fit with the rest of
PHP.

That makes sense to me as well; having conflicting properties due to
multiple traits implementing them is a good way to lead to inconsistency
and difficult to test/predict code.

I will agree up to a point. "Dude, this will probably break" is a worthwhile message to give. At the same time, though, there does need to be a way for the developer to say "I know that; trust me, I know what I'm doing". Otherwise, having two traits that are supposed to operate on the same base data will become needlessly complicated with return-by-ref accessors that may also collide.

E.g., if I have three traits that all operate on an internal array, and a dozen classes that use them, I do want class A to have traits 1 and 2, class B to have traits 1 and 3, etc., without needing three extra accessors lying around that serve no purpose other than to work around an unnecessary PHP restriction. (Stack calls in PHP are not free, aside from the ugly code that results in.)

Perhaps if both traits use the same variable name, visibility, *and* default value then there is no error?

I suspect this issue dovetails with the Traits-and-interfaces thread from earlier.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to