Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks

[Nathan Nobbe]

On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton <chadful...@gmail.com> wrote:

> On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe <quickshif...@gmail.com>
> wrote:
> > On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl <m4r...@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