Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55851
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH73KYWeHsxz=Qe0zBA08yhUx2BULwBFGnG0jJxtNGvHUQ@mail.gmail.com>
References: <CAH-PCH63GUHELTMrG2pRXd5i44U0+LpZhri95aVabKNN=6xgdA@mail.gmail.com>
	<D8BEB8F1-69AA-4291-B514-C6B5494F45BB@stefan-marr.de>
	<CAH-PCH73KYWeHsxz=Qe0zBA08yhUx2BULwBFGnG0jJxtNGvHUQ@mail.gmail.com>
Date: Mon, 17 Oct 2011 22:59:49 +0200
Message-ID: <CAH-PCH7JRZEjVC22eZ5vpWbXLkmgXOT8nw5Mo7PMM3UZxy0E_Q@mail.gmail.com>
To: Stefan Marr <php@stefan-marr.de>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf3056303533bad904af84e3a6
Subject: Re: typehinting traits
From: tyra3l@gmail.com (Ferenc Kovacs)

--20cf3056303533bad904af84e3a6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 17, 2011 at 8:19 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

>
>
> On Mon, Oct 17, 2011 at 8:00 PM, Stefan Marr <php@stefan-marr.de> wrote:
>
>> Hi Ferenc:
>>
>> On 17 Oct 2011, at 19:41, Ferenc Kovacs wrote:
>>
>> > Hi Stefan,
>> >
>> > Multiple people asked me that how they can expect/check that a given
>> object uses a trait or not.
>> > Of course one could write the concrete methods as a trait and always u=
se
>> a given interface for typehints, but I can't see why shouldn't instanceo=
f
>> and typehints in general work for traits.
>> > Is the any technical or maybe theoretical argument against this?
>>
>> Originally I proposed traits including the semantics that traits directl=
y
>> implement interfaces.
>>
>> The discussion is somewhere here:
>> http://www.mail-archive.com/internals@lists.php.net/msg33935.html
>>
>> I think Sebastian was the person with the strongest opinion on that
>> particular issue:
>>   http://www.mail-archive.com/internals@lists.php.net/msg33948.html
>>
>> And I tend to agree with him.
>>
>> Currently I think along the following lines:
>>
>>  A trait is not a full unit of reuse!
>>  A class is.
>>  Don't use traits where you should use classes and composition.
>>  Traits do not guarantee anything, if you want to be sure your invariant=
s
>> hold, use classes and composition.
>>
>>  Traits allow to reuse behavior in a much more flexible way, but they do
>> not replace classes.
>>
>> And, well, then there is this:
>> https://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_im=
plement_interface
>>
>> That should make sure that people can use interfaces for the purpose
>> envisioned here.
>>
>> For reference, there is also: https://bugs.php.net/bug.php?id=3D55613
>>
>>
>> But aside of the things I said before:
>>  - theoretically: keeping interfaces and traits apart is a good, clean
>> language design decision.
>>  - practically: people LOVE ugly languages, because they get things done
>>
>> So, well, I can't claim anything about value here.
>> The current situation might be more friendly to the teacher.
>> Another design might offer more freedom/power...
>
>
> Thanks for the clarification.
> Without either having the ability to check a trait or implement an
> interface for a trait, or at least implementing the require syntax, I thi=
nk
> that it isn't really a non-fragile solution for my question.
> AFAIK the only solution available currently is something like:
>
> <?php
> interface testTraitInterface{
>
> }
>
> trait testTrait{
>
> }
>
> class testClass implements testTraitInterface{
> use testTrait;
> }
>
> $tc =3D new testClass;
> var_dump($tc instanceof testTraitInterface);
>
>
> Which is pretty weak of a solution, however if we only thinks traits as a
> macro, this is enough, but then why bother with the as and insteadof, tra=
its
> composed traits and such?
> I think we will have much more feedback with the release of 5.4, so maybe
> we can re-consider extending the implementation for the next version.
> And I agree that it is the best to only release what we are confident in,
> and I'm happy that we waited a version for correctly implementing Closure=
s
> for objects.
>
> Thanks again for the clarification and for your work on traits!
>

Jeff Carouth pointed out(
https://twitter.com/#!/jcarouth/status/126030715514138624) that we have
class_uses() (https://bugs.php.net/bug.php?id=3D55266), would be nice havin=
g
that in the documentation.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--20cf3056303533bad904af84e3a6--