Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35755
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <1A.6C.30812.E5C50C74@pb1.pair.com>
To: internals@lists.php.net
Date: Sat, 23 Feb 2008 11:48:15 -0600
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
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> <47BF4D31.2040700@chiaraquartet.net>
In-Reply-To: <47BF4D31.2040700@chiaraquartet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: spam.goes.in.here@gmail.com (Joshua Thompson)

Gregory Beaver wrote:
> 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.

I could see this becoming a problem when it plays along with namespaces. 
Let me modify your example a little bit to show what I mean.

Some/Name/Space/A.php
<?php
namespace Some::Name::Space;
trait A {
   function myfunc(){ echo 'myfunc';}
   function a(){ echo 'Some::Name::Space::A::a';}
}
?>

Some/Other/Name/Space/A.php
<?php
namespace Some::Other::Name::Space;
trait A {
   function a(){ echo 'Some::Other::Name::Space::B::a';}
   function another(){echo 'another';}
}
?>

Blah.php
<?php
class Blah extends... implements...
   traits
     Some::Name::Space::A,
     Some::Other::Name::Space::A {
}
$a = new Blah();
$a->myfunc(); // myfunc
$a->a(); // Some::Other::Name::Space::B::a
$a->another(); // another
$a->{'Some::Name::Space::A::a'}() // Some::Name::Space::A::a
?>

I think this could lead to some problems that namespacing is trying to 
solve. Also, what happens if you decide to refactor one of the traits 
and change its name or namespace. You would then have to search for 
every use of an "autoaliased" method. I think the original proposal is 
much better in this regard, because you only have to find the classes 
that use the trait.

Another thing that bothers me about this idea is that the order that 
traits are added to a class determines which methods the class will 
have. This seems more and more like a mixin. I like the idea that the 
programmer has to make the choice over which implementation. It should 
be easy for the programmer to decide on one of these three:
   1. Use one of the trait's implementations of the method and exclude
      all others (and possibly provide an alias to them).
   2. Override the method in the class with a custom implementation.
   3. Alias each of the methods and use them in the overridden method
      implementation.

One more thing that I do not like about the auto aliasing is flattening. 
If I want to flatten all the traits into my class, I don't know of a way 
to make a method called {'Some::Name::Space::A::a'} inside the class in 
userspace (even though the interpreter can obviously handle it.

-- 
"Joshua Thompson" <spam.goes.in.here@gmail.com>
<http://www.schmalls.com>