Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51244
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com.au from 98.139.91.98 cause and error)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com.au;
  h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=jkgZHy4PAyB9mzjJkM7tGb5PqK5npeZ7Vp92EdzLxEtIbvJa5WMevQn0xlNRmPqE4dsu8tLb0l5Zh5DHAUy1Z/LXypulfw7aoyUKztRCYKXCB809z82C880BKpWE5n298j5BU1SDkwPt9CM7ZLMIdlQMINuO5WfwuezJnhitJYQ=  ;
Message-ID: <4D285AF2.2080902@yahoo.com.au>
Date: Sat, 08 Jan 2011 23:39:14 +1100
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 ThunderBrowse/3.3.4
MIME-Version: 1.0
To: Stefan Marr <php@stefan-marr.de>
CC: internals@lists.php.net
References: <4D206CA4.6060004@yahoo.com.au> <9284588E-446F-4C2D-B747-340D2F2D4E25@stefan-marr.de>
In-Reply-To: <9284588E-446F-4C2D-B747-340D2F2D4E25@stefan-marr.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Extensions to traits
From: mail_ben_schmidt@yahoo.com.au (Ben Schmidt)

Hi again, Stefan,

Continuing the conversation.

On 7/01/11 10:18 AM, Stefan Marr wrote:
> On 02 Jan 2011, at 13:16, Ben Schmidt wrote:
>> Extension
>> - - - - -
>>
>> 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.
>>
>> 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.
>>
>> 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?

Well, I hadn't thought about it before. :-)

But yes, I think that makes perfect sense.

> 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.

One complication I hadn't thought of before is whether it should be
possible to access trait:: methods and properties in different objects.
And if it should be, what syntax to use. $that->trait::method() seems
somewhat ugly to me. That would also suggest we should use
$this->trait::method() for the same-object case.

> Certainly an interesting approach.
>
> Has someone else an opinion on that?

I think actually this is the most important part of my proposal, so if
it could be accepted, I would be very pleased. Obviously it does need a
bit more thought and discussion yet, though.

>> Overriding
>> ==========
>>
>> Limitation
>> ----------
>>
>> 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?

Yes. 'Class proper' = 'class itself'. We seem to use 'proper' in English
as an adjective after a noun with a Latin-like sense of 'own/itself'. I
guess we probably got it from French, and surprisingly it hasn't died
out.

Cheers,

Ben.