Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51002
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=ZfEiP6Fh5PpS2b3zl4367CfqeE1u+2iFEuZNtHmoCTilnp9L2sdVGGF6yKWfJVoJ3g
         xJlxXNLcnDt6LRQCrlUU5JwindMj2VD9/w6ZmGgA/UC7L6Gud9lv6SLN4KkRcan5BbRq
         UCBTU2jJF7/6TVspOAA1tAWrZNnddXvnRfFZs=
MIME-Version: 1.0
In-Reply-To: <B8.70.39602.895820D4@pb1.pair.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>
	<B8.70.39602.895820D4@pb1.pair.com>
Date: Fri, 10 Dec 2010 14:06:37 -0700
Message-ID: <AANLkTi=O0dj9a8M7YbwLCb8FPq15uQHhWZpb3wbT5MVQ@mail.gmail.com>
To: "Matthew Weier O'Phinney" <weierophinney@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e6d7e101e083a4049714bad3
Subject: Re: [PHP-DEV] Traits expecting interfaces implicitly leads to
 expensive runtime checks
From: quickshiftin@gmail.com (Nathan Nobbe)

--0016e6d7e101e083a4049714bad3
Content-Type: text/plain; charset=UTF-8

On Fri, Dec 10, 2010 at 12:55 PM, Matthew Weier O'Phinney <
weierophinney@php.net> wrote:

> On 2010-12-10, Nathan Nobbe <quickshiftin@gmail.com> wrote:
> > --0016e6dbe7fb8861a1049712ad63
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton <chadfulton@gmail.com>
> wrote:
> >
> > > 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.  We'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.  The 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.  I know the notion
> of
> > compile time in a scripting language like PHP is much less removed from
> that
> > of C++, Java etc, however there is a notion of it there, obviously.
>
> To me, putting this into the language feels like overkill.
>
> Unless you're using an opcode cache, the notion of compile time as a
> differentiation from runtime in PHP has little relevance -- you still
> only find out when the script executes.
>

*Only* if you hit the line of code at runtime that would destroy your
script; often times this doesn't happen until it's too late, and the code
has made it to production.  And there is a notion of compile time in PHP,
I'm not sure what it's referred to by the internals group, but abstract
methods and interfaces definitely constitue compile time checks to me.


> There's already a way to mitigate this as well: write a testing suite
> for your application, and exercise it often. If you write your tests
> well (targeting the discrete behaviors of your application), then most
> likely they'll catch such errors -- allowing you to fix them before you
> deploy.
>

Right, so you have to do tons of extra work (writing unit tests) which have
to actually test every potential line of failure, when this could just
simply be caught up front w/o any second guessing whether or not you've
covered all cases in your tests.  I'm not against unit tests at all, just
saying it's much easier to guarantee you're safely using a trait w/ a
compile time check rather than deferring the application author to test
suite development.

-nathan

--0016e6d7e101e083a4049714bad3--