Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50998
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=WSQ96CKSleQytf7Irvwn74bS3n3BgtJFDU6vXIyz6dFXwXoemav2NOEfDKFEcc30p2
         xKyZ7c8CALPfbk0E/HRWpsxwzLxS+gTffrZl6yl1QqLpSwjkiXJQxOUxHFojFLUkqk8Z
         L2meZmleSEFqP1FvkdjVaBLR+bkkFLgaagJm8=
MIME-Version: 1.0
In-Reply-To: <AANLkTi=Hfd-466K2UM1NbL9LFVBys0egWuF1dOgM05zH@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>
Date: Fri, 10 Dec 2010 11:39:43 -0700
Message-ID: <AANLkTikEX9Cb46D0hAbepTFZyfRyLKdYocw+jPOLz=DF@mail.gmail.com>
To: Chad Fulton <chadfulton@gmail.com>
Cc: Martin Wernstahl <m4rw3r@gmail.com>, Stefan Marr <php@stefan-marr.de>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e6dbe7fb8861a1049712ad63
Subject: Re: [PHP-DEV] Traits expecting interfaces implicitly leads to
 expensive runtime checks
From: quickshiftin@gmail.com (Nathan Nobbe)

--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.

Also, I would suggest this feature be optional, so there is no need to use
it if you don't like it.  But for those of us who would like to defer as
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.  However, 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 will
mostly eliminate the need for the delegate pattern, see my quick example.

<?php
class MainClass {
  private $_oDelegate = null;

  function addDelegate() {
      $this->_oDelegate = new Delegate($this);
  }
}

class Delegate {
  private function $_oMain = null;

  /// delegate gets to say what it can be used with via type hinting
  function __construct(MainClass $oMainClass)
  {
    $this->_oMain = $oMainClass;
  }
}
?>

Imagine how much cleaner this could be w/ traits, yet just as expressive

<?php
class MainClass {
  use Delegate;
}

trait Delegate require MainClass {
 ...
}
?>

-nathan

--0016e6dbe7fb8861a1049712ad63--