Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51017
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.45 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:date:message-id:subject:from:to
         :cc:content-type;
        b=Dq42zflCBQmt6Kp+0P3rnFXBx3ZFk/6cXY8h92yZLKubVhdNPX/lhBIafH5R1JNbY8
         z8k4j0DmahN614U7PgEMH7qb87xiV/FAPP0dNvgEQGFV6HH6bsiiWkYjHRYSuLgkWp67
         e4NPlKmtHDYFnx1e7xjGI4UlIdjGJdr20lsok=
MIME-Version: 1.0
In-Reply-To: <002101cb9a08$7b7ebb30$727c3190$@com>
References: <AANLkTim9wJSM9XrZu7JHmvX04ZfE+Bikz_-SP+6aJx79@mail.gmail.com>
	<ED4CBBC5-E94B-4FF7-A104-1298812D7844@stefan-marr.de>
	<002101cb9a08$7b7ebb30$727c3190$@com>
Date: Sun, 12 Dec 2010 14:33:19 -0700
Message-ID: <AANLkTikeS7HN3qvg_hQ4Jb6g8ByPY936WmDJP6GCUG6e@mail.gmail.com>
To: Jonathan Bond-Caron <jbondc@openmv.com>
Cc: Stefan Marr <php@stefan-marr.de>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e6d7e101166c7b04973d56ae
Subject: Re: [PHP-DEV] Traits expecting interfaces implicitly leads to
 expensive runtime checks
From: quickshiftin@gmail.com (Nathan Nobbe)

--0016e6d7e101166c7b04973d56ae
Content-Type: text/plain; charset=UTF-8

On Sun, Dec 12, 2010 at 7:25 AM, Jonathan Bond-Caron <jbondc@openmv.com>wrote:

> On Sat Dec 11 10:25 AM, Stefan Marr wrote:
> >
>
> http://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_impleme
> nt_interface
> >
> >
> > Are there any objections to implementing this?
> >
>
> It's not a bad idea, though I haven't found a strong need for it in the way
> I plan to use traits.
>

Do you intend to use traits as reusable implementations of interfaces?  If
not, I could see why this feature isn't of interest to you :)


> It also turns a trait into something more complex 'copy & paste' code with
> requirements/dependencies.
>

I think copy & paste is a good way to conceptualize traits, but feel,
practically, they're a bit more complex than that w/ conflict resolution,
traits composed of traits, and the issue w/ attributes Stefan has brought
up.  Essentially, there are already rules being added around the copy &
paste concept.  Also, this feature is mostly an extension of the abstract
keyword concept in traits, which they already support.


> -1 on using 'require' (T_REQUIRE token), an option could be 'within'
>
> trait IteratorUser within Iterator {
>     function foo() {
>        $next = $this->next();
>        ...
>    }
> }
>
> class MyIterator implements Iterator {
>  with IteratorUser;
> }
>
> So the 'with/within' tokens would apply to traits.
>

I feel 'expect', 'need', 'require' etc sound better, matter of opinion
really, but it sounds like from an internals perspective it's preferred to
reuse existing keywords if possible.

Overall I feel -1, more use cases around "Trait expresses a requirement for
> the composing class" would help, it seems like useful theory...  not
> convinced it's worth the trouble.


If you see the value in the abstract keyword in abstract classes or moreover
interfaces in general, I'd consider the value of this feature equal.  Of
course not everyone uses abstract classes or interfaces :D

-nathan

--0016e6d7e101166c7b04973d56ae--