Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50999
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type:content-transfer-encoding;
        b=OfSoLC9axo7EtZOBBTVhwsZz2Q0SRMJHrrWFWZsps39xcs0q564OmPUmGrm5eyrNtn
         w2u69O5RzDzW2xnQYEa5Du/pJZJ8clbRrYzryYD/I6nuuv6WcQhFAG5E4KtnIoV5oSj8
         QIrtQgB1tTutA3lT4cMUcaGTrt1jbKzbpxrA8=
MIME-Version: 1.0
In-Reply-To: <AANLkTikEX9Cb46D0hAbepTFZyfRyLKdYocw+jPOLz=DF@mail.gmail.com>
References: <AANLkTim9wJSM9XrZu7JHmvX04ZfE+Bikz_-SP+6aJx79@mail.gmail.com>
 <9CD87200-33CB-40BE-A81C-36FD7471F59C@stefan-marr.de> <AANLkTinEUskDW=wncdQz+p4awnXt+n+FRHwUVsH1E0ac@mail.gmail.com>
 <9A31F2F9-ED6B-4BE5-A6E2-EB4536E8667F@stefan-marr.de> <AANLkTi=qDh-F6_DSgZELaBd5jfsqEJN4yqEYusdnwY-v@mail.gmail.com>
 <C75E8AE0-97BE-4FAA-B925-DEAED6D6AE69@stefan-marr.de> <AANLkTinryh-9R5JJj_GynF7OCCt5QE1X8RmdGzFdGJWB@mail.gmail.com>
 <AANLkTinkGJ2Ev4KzfFPX_ybyFKq7VKsx1itZr5o_REmT@mail.gmail.com>
 <AANLkTi=Hfd-466K2UM1NbL9LFVBys0egWuF1dOgM05zH@mail.gmail.com> <AANLkTikEX9Cb46D0hAbepTFZyfRyLKdYocw+jPOLz=DF@mail.gmail.com>
Date: Fri, 10 Dec 2010 11:39:07 -0800
Message-ID: <AANLkTimVtm5zudv82EGBZkAedWAFfc5-to-vaVCFBKVB@mail.gmail.com>
To: Nathan Nobbe <quickshiftin@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Traits expecting interfaces implicitly leads to
 expensive runtime checks
From: chadfulton@gmail.com (Chad Fulton)

On Fri, Dec 10, 2010 at 10:39 AM, Nathan Nobbe <quickshiftin@gmail.com> wro=
te:
> On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton <chadfulton@gmail.com> wrot=
e:
>>
>> On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe <quickshiftin@gmail.com>
>> wrote:
>> > On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl <m4rw3r@gmail.com>
>> > wrote:
>> >
>> >> First i have to say that I am not a PHP internals developer, but as a
>> >> user
>> >> I think it would maybe be better to just let the trait use the
>> >> implements
>> >> keyword, and "copy" that to the classes utilizing the trait?
>> >>
>> >
>> > This is actually in the RFC as a rejected proposal
>> >
>> > http://wiki.php.net/rfc/traits#rejected_features
>> >
>> > But what I'm talking about is something different. =A0We're not trying=
 to
>> > say
>> > 'these are the methods implemented in the trait', rather, 'this trait
>> > expects a class it is used with to be of a certain type or implement a
>> > certain interface' for the trait to do its job.
>> >
>> > -nathan
>> >
>>
>> Shouldn't the burden be on the programmer to make sure the trait works
>> with the class using it rather than on the compiler? If they try to
>> use a trait that requires methods that don't exist, it will error out
>> anyway, so it won't be difficult to debug.
>
> Well I know PHP is a dynamic language but what about all the compile time
> features that have come along over the years. =A0The abstract keyword for
> example vs. the PHP4 way of implementing an 'abstract' method which was
> triggering an error in the default implementation in a base class.
> One of the main things a lot of PHP programmers I've worked with hate is
> waiting for code to hit production and encountering a runtime error w/
> something that could have been caught at compile time. =A0I know the noti=
on of
> compile time in a scripting language like PHP is much less removed from t=
hat
> of C++, Java etc, however there is a notion of it there, obviously.
> Also, I would suggest this feature be optional, so there is no need to us=
e
> it if you don't like it. =A0But for those of us who would like to defer a=
s
> much type checking to the compiler as possible so we don't need runtime
> checks all over our code or prayers that we've tested every line before
> production, it would certainly be nice.
> Lastly, you may know that traits will allow PHP programmers to move away
> from the delegate pattern which is a common workaround to multiple
> inheritance at this point. =A0However, in speaking with a colleague over =
the
> concept I'm proposing yesterday we discovered the delegate model actually
> does allow you to specify which class/interface the delegate is used w/, =
it
> would be sad not to see comparable support in the trait feature which wil=
l
> mostly eliminate the need for the delegate pattern, see my quick example.
> <?php
> class MainClass {
> =A0=A0private $_oDelegate =3D null;
> =A0=A0function addDelegate() {
> =A0=A0 =A0 =A0$this->_oDelegate =3D new Delegate($this);
> =A0=A0}
> }
> class Delegate {
> =A0=A0private function $_oMain =3D null;
> =A0=A0/// delegate gets to say what it can be used with via type hinting
> =A0=A0function __construct(MainClass $oMainClass)
> =A0=A0{
> =A0=A0 =A0$this->_oMain =3D $oMainClass;
> =A0=A0}
> }
> ?>
> Imagine how much cleaner this could be w/ traits, yet just as expressive
> <?php
> class MainClass {
> =A0=A0use Delegate;
> }
> trait Delegate require MainClass {
> =A0...
> }
> ?>
> -nathan
>

As a note, I'm not strongly opposed to this proposal, since I don't
think it would do any harm. It just seems to me like a "kitchen sink"
feature.

The issue for me is that traits, as I understand them, are there
primarily for horizontal code re-use via compile-time "copy/paste".
With that in mind, I feel like the developer is responsible for making
sure the methods they copy into their classes make sense, just as they
would have to do if they physically copied and pasted them.

I think your example above isn't quite what you meant to show, since
you're requiring a specific class and not an interface (since PHP only
allows one class definition for a class name, you're not gaining
anything via traits, since the trait could only be used for that
specific class, in which case why not just have the code in the class
in the first place?).

If we take your example in a more general case using interfaces, I
still can't see what the benefit is. All it does is provide a more
explicit and immediate error message for developers (e.g. instead of
"method not found" error when the bad method call is made at runtime,
you get a "classes using trait <trait> must implement <interface>" at
compile time).

Again, I'm not against it, but maybe be too much hand holding, since
the developer should make sure using the trait makes sense first?