Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51243
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com.au from 98.139.91.100 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=VH35PDIGJragTyzggrarCDMa171K4Yft0b1OU2GQ+tPcbqsMQom6YuDPy0du1BC5RTCykPr10Zk01t/Ik3jFlhV815BDjINgU6+FHpJvSkCyL9Mux29hIDwUhV220sC2/6oHDVMkidI8+c6XQylX1+DdaFL0WzupimAL2CWoILI=  ;
Message-ID: <4D284D1D.6080101@yahoo.com.au>
Date: Sat, 08 Jan 2011 22:40:13 +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: Stefan Marr <php@stefan-marr.de>
CC: internals@lists.php.net
References: <4D206CA4.6060004@yahoo.com.au> <767E5516-E475-46E8-AE5C-9406D90881D7@stefan-marr.de>
In-Reply-To: <767E5516-E475-46E8-AE5C-9406D90881D7@stefan-marr.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Extensions to traits
From: mail_ben_schmidt@yahoo.com.au (Ben Schmidt)

Hi, Stefan,

Thanks for considering my ideas so carefully and for your detailed
replies.

> The reason to go with insteadof is that the assignment syntax hides
> changes that might cause problems.
>
> Thus, when you change any of the traits participating in a composition
> in a way that a conflict would be introduced, the assignment syntax is
> hiding this. With the insteadof syntax you are actually forced to
> reevaluate whether your code still makes sense and include the
> offending change explicitly.

OK. That makes sense. I'll rework any surviving parts of my proposal to
be based on the insteadof syntax.

> This does not only have the mentioned benefit of making problematic
> changes in the traits hierarchy explicit, but the second reason to go
> with this design was the wish to have a 'exclude' operator without
> actually having a full-exclude operator. Thus, there is no way that
> you can leave out arbitrary methods from a trait.

This seems wrong to me. Doesn't it go against the stated principle that
the class author should have full control of traits? How is it full
control if you can't exclude a method? What is the reasoning behind this
wish not to have a full exclude operator?

> Hm, don't understand you here either. I needed to look up what
> impoverished actually means, you are not insulting me here, right?
> Just kidding ;)

Sorry. I forget that a lot of you people aren't native English speakers
and sometimes funny words like that slip in! I think all you people who
communicate so fluently in additional languages are amazing.

>> No error or warning will be
>> generated, but the class will not work as intended; probably it will
>> infinitely recurse; a nasty problem to track down.
>> Furthermore, even if the incorrect method call didn't occur, there would
>> be data-sharing problems, as both the ErrorReporting trait and the
>> class' print() function make use of the $output data member,
>> unintentially sharing data.
>
> Well, short answer: it is compiler-assisted copy-and-past, why isn't
> that trait just providing the glue that gets your class the necessary
> functionality to use a proper ErrorReporting class?
>
> Sorry, I know not a really helpful answer, but I hope that examples
> shows how I see traits.
>
> They are for reusing code in situations where the other concepts just
> break down. Not meant to replace those.

I agree. I did say it was a poor example. I think the kinds of
behavioural problems it demonstrates, though, could be found in
situations where traits *are* truly appropriate.

No need to argue over examples, though. Plenty of other things to argue
about. :-)

>> Warnings
>> - - - -
>>
>> To avoid silent unintended shadowing, I suggest issuing a warning when a
>> conflict between trait and class methods occurs. So this would trigger
>> a warning:
>>
>>    trait SaySomething {
>>       public function sayIt() {
>>          echo "Something\n";
>>       }
>>    }
>>    class Sayer {
>>       use SaySomething;
>>       public function sayIt() {
>>          echo "Hello world!\n";
>>       }
>>    }
>
> Ok, well, we could see the actual class body as another trait, and
> require it to follow the same composition rules, and that way make
> require the programmer to use insteadof in such a case.
>
> In return that would mean, that traits are not part of the inheritance
> chain at all anymore.
>
> Thus, first is the inheritance chain used to build up the
> implementation of a class, and afterwards all the traits are composed,
> while the original class is seen as another trait.
>
> That idea has certainly something to it.

Yes, I think that would be good.

Having read your other emails, as well as having allowed my proposal
itself to clarify in my mind, I'm beginning to think it might be
clearest and cleverest to avoid inheritance altogether with traits. Of
course, this is in contrast to my original proposal, which was to
increase traits' participation in inheritance.

In this case, parent:: will always do what you expect then, and there's
no need for prev::.

Now to the other emails!

Ben.