Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51231
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 81.20.134.149 cause and error)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <002d01cba1ee$7671d0d0$63557270$@com>
Date: Thu, 6 Jan 2011 14:38:34 +0100
Cc: <larry@garfieldtech.com>,
 <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F8CFF755-5277-46ED-B6C1-973B1B746823@stefan-marr.de>
References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de> <AANLkTi=dz1pu7B+1k-xAbCRPmFx24J=27ABaWLRuPwqK@mail.gmail.com> <D9ED43A9-833E-4644-9DFC-DE89CF83656F@stefan-marr.de> <201012132027.59678.larry@garfieldtech.com> <76C593EE-BCCA-4BBD-B625-B6AE9340B20C@stefan-marr.de> <73.1D.35939.D413E0D4@pb1.pair.com> <BE066A6A-908C-46DD-AE2F-12222B206997@stefan-marr.de> <8F.32.11788.5FF5F0D4@pb1.pair.com> <4D0F7E99.8050705@garfieldtech.com> <764A364B-173B-401B-83FA-A61D45BE99CB@stefan-marr.de> <002d01cba1ee$7671d0d0$63557270$@com>
To: Jonathan Bond-Caron <jbondc@openmv.com>
Subject: Re: [PHP-DEV] Traits and Properties
From: php@stefan-marr.de (Stefan Marr)

Hi Jonathan:

Sorry, was not able to get back to those discussions earlier.


On 22 Dec 2010, at 16:39, Jonathan Bond-Caron wrote:

> There are two remaining questions I have:
> 1) How do traits affect the reflection API?
Johannes implemented some features in the Reflection API.

However, they are very ad-hoc, and there are some points which could be =
designed differently to make the concepts more clear.

On of those things is that you actually use ReflectionClass to reflect =
on a trait.
That is really an implementation detail, and should be changed to not =
confuse anyone on a conceptional level. We should not expose that kind =
of engine/implementation detail.

Thus, there remains stuff to be done about reflection. In general, I =
would like to be able to access all information that was in the source =
code. However, time constraints are an issue for me. If there would be a =
new release date for an alpha or something, I think I could get some =
time to work on it...


> 2) Do we want to be able to declare trait requirements for properties =
and
> methods? If so what syntax?
Well, there was the proposal to use require to express constraints for =
the composing class, which is something I liked.

However, I would not go to support properties, too, since I still =
maintain the opinion that we do not actually do something about state =
with regard to traits.=20


>=20
> A note on the syntax proposed by Nathan:
> trait require Foo
>=20
> An option could be:
>=20
> trait Foo {
>  require {
>     public $var;
>     function ratio();
>  }

Hm, well, we already got abstract methods for the methods part.


> trait Bar {
>  require interface Iterator;
> }
And expressing the requirement for an interface or an abstract class =
seems to be the only thing missing, I think.

However, I would not put that in the body but into the hat.

trait Bar require OneSpecificClass, AndPossiblyAnInterface, =
OrPossiblyAnotherInterface {}


>=20
> The idea comes from:
> http://code.google.com/p/es-lab/wiki/Traits
>=20
> I found this trying to look for alternative keyword for 'require'.
Yes, Tom worked on that a while ago, but it was to easy to implement it =
in a library for JavaScript. To easy to be considered for a language =
feature...

Best regards
Stefan

--=20
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525