Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56068
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain openmv.com from 64.15.152.204 cause and error)
To: "'Nathan Nobbe'" <quickshiftin@gmail.com>,
	<internals@lists.php.net>
References: <CAL5nwZ6RF8Z3FV1vKgxoFZoBJiRp_qBNSx5MXAe_8-jbmj5OOA@mail.gmail.com>
In-Reply-To: <CAL5nwZ6RF8Z3FV1vKgxoFZoBJiRp_qBNSx5MXAe_8-jbmj5OOA@mail.gmail.com>
Date: Fri, 4 Nov 2011 09:11:53 -0400
Message-ID: <004401cc9af3$5306b260$f9141720$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcyQlhIYxiHvLBALRAKBC3JY9BoY6wKWSA7g
Content-Language: en-ca
Subject: RE: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
From: jbondc@openmv.com ("Jonathan Bond-Caron")

On Sat Oct 22 04:38 AM, Nathan Nobbe wrote:
> Hi folks,
>=20
> With a 5.4 release right around the corner I'd like a moment of your=20
> time to reconsider this issue [1].
>
> Just curious why it died on the table if several folks saw value in=20
> it, including Stephan who I gather is the primary architect of traits.
>=20
> The dispute regarding the feature was the merit of a 'compile time'
> check vs placing the burden on the developer to ensure all methods in=20
> a trait are provided by the class in which it is used.  In an earlier=20
> conversation about traits Stefan said this:
>=20
> "Yes, Traits are meant to be compile-time only, they are not used to=20
> introduce typing relationships."
>=20
> Which makes me even more comfortable about the merit of another=20
> compile time check.  As I argued in the original thread, the feature=20
> is merely an embellishment atop the already supported use of the=20
> 'abstract'

I think it's up to Stefan's experience & wisdom.

To really cover all use cases, it might be worth looking into using a =
require{} block as a way to list the requirements for the composing =
class (and get rid of the abstract syntax).
e.g.

trait Bar {
  require {
    function foo();
    private $_prop;
    implements Iterator;
  }

  function moveNext() {
     $this->foo();
     $this->_prop =3D 'hello';
     $this->next();
  }
}

class Foo implements Iterator {
   use Bar; //ok
   function foo() {}
   private $_prop;
   function next() .... iterator methods
}=20

class FooFailure {
   use Bar; // E_FATAL: composing requirements not met (implements =
Iterator, function foo())
   private $_prop;
}

Traits is already an advanced concept, a conservative approach would be =
to remove the 'abstract' check and see how people end up using traits.

If there's enough use cases (not foo/bar examples) out there that need =
compile time checks, add the proper syntax for it.