Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51096
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.27.228 cause and error)
Message-ID: <4D0F7E99.8050705@garfieldtech.com>
Date: Mon, 20 Dec 2010 10:04:41 -0600
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: internals@lists.php.net
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> <76C593EE-BCCA-4BBD-B625-B6AE9340B20C@stefan-marr.de> <73.1D.35939.D413E0D4@pb1.pair.com> <BE066A6A-908C-46DD-AE2F-12222B206997@stefan-marr.de> <8F.32.11788.5FF5F0D4@pb1.pair.com>
In-Reply-To: <8F.32.11788.5FF5F0D4@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Traits and Properties
From: larry@garfieldtech.com ("larry@garfieldtech.com")

On 12/20/10 7:53 AM, Matthew Weier O'Phinney wrote:
> On 2010-12-19, Stefan Marr<php@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