Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51511
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com.au from 98.138.91.63 cause and error)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com.au;
  h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=3WaJA3LjOo00UuYL1OOLIJzExBO/vB69TFNjWqlIm3z7BnMga7GzVxrpQDi9d0HF/E/amSuF1dtQdZSugstTBdcqf3OWBKYaW9bv08PRBvbHO49k8bxiSEtW4FHJrou/f6vEeB2OVOrMNscmg+MTUiIlvmholcjlXFjVBnO6Qq4=  ;
Message-ID: <4D64E00A.4060900@yahoo.com.au>
Date: Wed, 23 Feb 2011 21:23:06 +1100
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 ThunderBrowse/3.3.4
MIME-Version: 1.0
To: Jonathan Bond-Caron <jbondc@openmv.com>
CC: internals@lists.php.net
References: <4D206CA4.6060004@yahoo.com.au> <005f01cbadc9$1172d080$34587180$@com> <4D284B8B.5040408@yahoo.com.au> <4D537DE1.2010309@yahoo.com.au> <36AB1B1C-1C92-475D-84C7-D0B0DB8FE462@roshambo.org> <4D541F8A.4050502@yahoo.com.au> <AANLkTim2qs_mnY5f9RX3GoqsqeLkaZnWxY_O3PEMhpn6@mail.gmail.com> <007101cbcd1d$a7ac3e60$f704bb20$@com>
In-Reply-To: <007101cbcd1d$a7ac3e60$f704bb20$@com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Extensions to traits
From: mail_ben_schmidt@yahoo.com.au (Ben Schmidt)

> That might seem odd but it's not inheritance.

Yeah. And that's my main concern with it. It seems like inheritance (and
is described like inheritance in the RFC at present--which is a
documentation issue that will need to be addressed in the manual
eventually), but it isn't. I feel it should be one or the other: either
have full inheritance semantics, or have full conflict-resolution
semantics like when trait methods conflict, at least by default. I think
the latter is better.

I'm really warming to the idea of using 'default' as I proposed in my
last email, though, as essentially doing what André suggested 'in
reverse'--i.e. a 'non-final' marker.

Ben.