Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51237
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: <4D206CA4.6060004@yahoo.com.au>
Date: Fri, 7 Jan 2011 00:18:35 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <9284588E-446F-4C2D-B747-340D2F2D4E25@stefan-marr.de>
References: <4D206CA4.6060004@yahoo.com.au>
To: Ben Schmidt <mail_ben_schmidt@yahoo.com.au>
Subject: Re: [PHP-DEV] Extensions to traits
From: php@stefan-marr.de (Stefan Marr)

Hi Ben:

Here the second part, on your extension proposal.

On 02 Jan 2011, at 13:16, Ben Schmidt wrote:

> Extension
> - - - - -
>=20
> I suggest these two problems can be simply solved by introducing two
> additional uses of the trait keyword: as a scoping keyword and an =
access
> specifier.
>=20
> As a scoping keyword, it would be used analogously to self. Method =
calls
> such as $this->print() could be replaced with trait::print() when the
> programmer desires to ensure that their trait method, and only their
> trait method, is called--when there is no intention that overriding
> should be possible. It would only be able to be used in a trait, and
> could only be used to reference methods or properties defined in the
> same trait, using their original name.
>=20
> As an access specifier, it would be used instead of public, private,
> etc. in trait definitions, to mean that the member (data or method) =
can
> and can only be accessed using the mechanism above (trait::).

Ok, that would actually get us around all the meta-programming problems.
When you say that the 'trait'-access modifier always requires the access =
via a specific keyword (trait::) then mangling the name should be =
possible.
On the other hand, what would iterating over the object properties show?
Multiple properties with the same name, like with inherited private =
properties I suppose?

And an occurrence of trait:: would mean, do a $this-> but mangle the =
name first with the trait's name the original definition was in. Should =
be possible, but would certainly impact the Zend Engine a bit more than =
what we have now.

Certainly an interesting approach.


Has someone else an opinion on that?



>=20
>=20
> Overriding
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Limitation
> ----------
>=20
> At present, the overriding semantics of traits are that a method =
defined
> in a class proper overrides a method defined in a used trait which in
> turn overrides a method defined in an ancestor class.
Bye the way, where comes that terminology from: class proper? We are =
talking about the body of a class, right?

Well, but I will stop here, and try to cover the rest in the next =
mail...

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