On Thu, Dec 9, 2010 at 4:04 PM, Stefan Marr <p...@stefan-marr.de> wrote:
> Hi Nathan:
>
>
> On 09 Dec 2010, at 23:42, Nathan Nobbe wrote:
> > What I'm getting at is the scenario when a trait is designed to be used
> in
> > concert with the class in which it is being used. In this case the trait
> > expects certain functions to be available on the class in which it is
> used
> > with. If the methods aren't there (or checked for at runtime) a fatal
> error
> > is raised.
> >
> > A quick example
> > <?php
> > class A {
> > use AHelper;
> >
> > function blah() {}
> > }
> >
> > trait AHelper {
> > function meh() {
> > // hoping we get used w/ instances of A ...
> > return $this->blah() * 5;
> > }
> > }
> >
> > class B {
> > use AHelper;
> >
> > /// waiting for a runtime error if blah() is ever called ..
> > }
> > ?>
> >
> > Do you see what I mean?
> No, do not really see what you are getting at.
>
> How is your approach using the instanceof checks (from the first mail)
> different from changing AHelper to require blah() by stating this
> requirement using an abstract method definition?
> For the trait it is not important where that method is implemented, it just
> has to be in the final composed class.
>
> So, why don't you want the following trait?
>
> trait AHelper {
> abstract function blah();
>
> function meh() {
> // hoping we get used w/ instances of A ...
> return $this->blah() * 5;
> }
>
> }
>
Ahh, I see how the abstract methods are working in traits now, I didn't
catch that from your first post; thanks for showing that to me.
> You want to avoid the fatal error during runtime, right?
>
Yes, exactly, and the runtime check for expected interface / class / method.
> Do you prefer dynamic checks over compile time checks?
Def not :D, however, I still think this paradigm is lacking. Don't you
think it makes more sense if I write a trait that expects a given interface
or class to be able to specify said interface/class in it's entirety with
just a single identifier rather than listing out all the methods?
For example, I think this would be ugly
<?php
trait IteratorHelper{
abstract public current();
abstract public key();
abstract public next();
abstract public rewind();
abstract public valid();
}
?>
essentially you're redeclaring the entire interface in the trait, the same
would be true of the public interface of an expected class. i think it
would be much more elegant to allow a specification on the trait declaration
itself, something like
<?php
trait IteratorHelper expects Iterator {
...
}
?>
-nathan
