Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51004
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.196 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=mueD5ahpLyyzyM1nyXBFJerQ4QMPCij5mbDqeyZt/NlWZdg8S9WOxL5LlqRuMycCmf
         F9Ro3awOOgeppqz6ar57QTMX0TfTf9ZssKk4Q8uFnCvNlshXuWyko+1u1KMY1c40jJ7/
         iMhMJnC6CEhx9u2vxZo6yHgIvB3+TDIAbWNb0=
MIME-Version: 1.0
In-Reply-To: <AANLkTi=BkmO3QhGJe5U0H41Cbpio2crUkNViwg8wH6WT@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>
 <AANLkTimVtm5zudv82EGBZkAedWAFfc5-to-vaVCFBKVB@mail.gmail.com> <AANLkTi=BkmO3QhGJe5U0H41Cbpio2crUkNViwg8wH6WT@mail.gmail.com>
Date: Fri, 10 Dec 2010 14:17:20 -0800
Message-ID: <AANLkTikV-RMV+vi6KWXHKY-qcjT7J1uQGnfAXVa+=fO7@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 1:00 PM, Nathan Nobbe <quickshiftin@gmail.com> wrot=
e:
>>
>> 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.
>
> Copy & paste itself leads to duplicated unmaintainable code, so traits ar=
e
> introduced (among other reasons) to prohibit this practice. =A0Why not ta=
ke it
> a step further and let a trait definition be as expressive as possible,
> eliminating ambiguity, right out of the gate?
>
>>
>> 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?).
>
> In retrospect Chad, that's a good point, and perhaps there is no reason t=
o
> allow marking of classes as required by traits.
>
>>
>> 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).
>
> Exactly, catch it at compile time rather than runtime, that's all it is
> really, just like the benefit of discovering a given subclass doesn't
> implement a given abstract method so that I don't go any further and run
> code guaranteed not to work.
>
>>
>> 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?
>
> Couldn't the same be said for a developer extending an abstract class, or
> implementing an interface? =A0And also, a developer is to look through th=
e
> entire definition of a trait to know which methods it's going to depend o=
n?
> =A0I know abstract is there as Stefan showed, but as we've both observed =
that
> approach can get messy quickly.
> -nathan
>

I think that you make a convincing argument. Thinking more about your
Iterator example, this idea makes a lot of sense and could be quite
useful.

Also, I was wrong about requiring a class. It could be very useful,
especially if it is an internal class (e.g. ArrayObject) which might
have many children, and of course in this case the parent can't be
changed.

I think the require keyword works well.