Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35739
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <47BF4D31.2040700@chiaraquartet.net>
Date: Fri, 22 Feb 2008 16:31:13 -0600
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: Marcus Boerger <helly@php.net>, php@stefan-marr.de, 
 Evert|Rooftop <evert@rooftopsolutions.nl>,
 Stanislav Malyshev <stas@zend.com>, internals@lists.php.net
References: <001c01c87264$3c01b4e0$b4051ea0$@de> <173732199.20080219175837@marcus-boerger.de> <1203452909.24580.9.camel@localhost> <1e12984d0802191323o710c6b8ej3a54af7901cf35f1@mail.gmail.com> <47BB4AC9.9070701@zend.com> <1e12984d0802191346x7c145d7fp14c01ec4e5993779@mail.gmail.com> <47BB4F49.1030904@rooftopsolutions.nl> <1e12984d0802191359p4f21c3acrdff4b86adfb4bf3@mail.gmail.com> <1495054633.20080220205951@marcus-boerger.de> <1e12984d0802201243gfa51f01i311891e8965ed51e@mail.gmail.com> <9EE7F229-0710-48E8-9A26-DC8031AF8979@pooteeweet.org> <1985981545.20080222134413@marcus-boerger.de> <47BEE001.9080602@chiaraquartet.net> <B9A7A220-6AB6-4511-8587-19F520EA5885@pooteeweet.org>
In-Reply-To: <B9A7A220-6AB6-4511-8587-19F520EA5885@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: greg@chiaraquartet.net (Gregory Beaver)

Lukas Kahwe Smith wrote:
>
>> I have been uncomfortable with the current trait suggestions because
>> they occur in the body of the class, whereas extends/implements is
>> outside.  I think there is a way to handle this, however.
>
> I dont agree here. traits are different. They do not affect "what" the
> class is. They change what it can do and as such the stuff should be
> defined next to properties and methods.
>>
>
>> <?php
>>
>> trait trait1 { function a(){}}
>> trait trait2 { function a(){}}
>> class Blah extends ... implements ... traits trait1, trait2, trait3 {
>> }
>> ?>
>
> Here it gets worse. Now if I refactor things into a trait, I have to
> start changing all uses of those methods.
>
> @Greg: I think you are going in the wrong direction here. 

I think you may be confused, because your statement about refactoring is
inaccurate - for most methods, there would be no change from the current
proposal.  In other words, in my example above, you could use
trait1::a() simply as Blah::a, for instance:

<?php
$a = new Blah;
$a->a();
?>

Only if one wanted to access trait2::a() would one need to either alias
via "function trait2::a as b" to use as "$a->b()" or explicitly refer to
"$a->{'trait2::a'}()"

To be absolutely clear, here is how it could work:

<?php
trait A {
function myfunc(){ echo 'myfunc';}
function a(){ echo 'A::a';}
}
trait B {
function a(){ echo 'B::a';}
function another(){echo 'another';}
}
class Blah extends... implements... traits A, B {
}
$a = new Blah();
$a->myfunc(); // myfunc
$a->a(); // B::a
$a->another(); // another
$a->{'A::a'}() // A::a
?>

So, as you can see, all of the trait methods are available as regular
methods except for A::a which is overridden by B::a.  If the order were
reversed, i.e. "traits B, A" then "$a->a()" would instead call A::a.

The current proposal would cause the above to fail with a name conflict
error rather than automatically aliasing.

Here is another example with the overriding syntax:

<?php
trait A {
function myfunc(){ echo 'myfunc';}
function a(){ echo 'A::a';}
}
trait B {
function a(){ echo 'B::a';}
function another(){echo 'another';}
}
class Blah extends... implements... traits A, B {
function B::a as private;
function A::a as a;
}
$a = new Blah();
$a->myfunc(); // myfunc
$a->a(); // A::a
$a->another(); // another
?>

Greg