Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35729
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.162.177 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=R5m6a6OEJlyc8PpmHhsnyGdtl0ZfIbY5SBbQK2wMQwBVPEr4E7BOpstX69dIvBCp/OY4N1KP2iuU1rQo/+OR3/OgUwXMP/SLtnAhY4Av0WcA98dXATPs1LkSX1GnEBxxEXWKw59J+mM5PYxfgyAklxyXSUw6bBj6m04wz87uucw=
Message-ID: <b5f7bf6c0802220732n142f409dq85845b8561b9fe9c@mail.gmail.com>
Date: Fri, 22 Feb 2008 10:32:37 -0500
Sender: david.coallier@gmail.com
To: "Lukas Kahwe Smith" <mls@pooteeweet.org>
Cc: "Gregory Beaver" <greg@chiaraquartet.net>, "Marcus Boerger" <helly@php.net>, 
	php@stefan-marr.de, Evert|Rooftop <evert@rooftopsolutions.nl>, 
	"Stanislav Malyshev" <stas@zend.com>, internals@lists.php.net
In-Reply-To: <B9A7A220-6AB6-4511-8587-19F520EA5885@pooteeweet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <001c01c87264$3c01b4e0$b4051ea0$@de>
	 <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>
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: davidc@php.net ("David Coallier")

On Fri, Feb 22, 2008 at 10:03 AM, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
>
>  On 22.02.2008, at 15:45, Gregory Beaver wrote:
>
>  > Marcus Boerger wrote:
>  >> Hello Lukas,
>  >>
>  >>  alright,
>  >>
>  >>   'foo as bar' is ok to me and does not even add a new keyword.
>  >> Ignore or any more keywords are bad and I also think that the correct
>  >> would be hide(ing). But as I further more explained it should
>  >> really be
>  >> something that only marks a method as private if at all. That can be
>  >> done as:
>  >>   'foo as private' since private is a keyword it cannot conflice
>  >> anyway.
>  >
>  > I like this solution.
>
>  Yes to me it seems like we can solve the entire "lack of
>  encapsulation" through aliasing/hiding by making the following changes
>  to the original proposal:
>
>  A trait may contain methods and properties. When importing a trait
>  into a class, all methods and properties are imported in a way that
>  makes them only visible within the trait (I dont like the use of
>  "private" here .. its what confused me in the first proposals of this
>  approach by Marcus/Andi). The user of the trait can however explicitly
>  make properties and methods from the trait visible to the class
>  importing the trait. Also the trait using class can explicitly say
>  that it wants to override a method/property in the scope of the trait.
>
>  This way:
>  1) there is little chance of accidentally breaking a trait
>  2) changes within the trait should not break anything in the trait
>  using class, unless the developer explicitly messed with the traits
>  internals in the class using the trait. in that case however he can
>  quickly spot the potentially problematic lines
>
>
>  > 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.
>

Fun that you mentionned that structure greg because I was thinking of
something along those lines. Something very similar actually but the
aliasing could look like this:

trait One {
    function name() { return __TRAIT__; }
    function removeMe() {}
}

trait Two {
    function name() { return __TRAIT__; }
}

class Reel traits One, Two
{
    override One::name with Two::name;
    remove Two::removeMe;
}


$object = new Reel();
echo $object->name();  // Echos "Two" of course.


I find that rather clean and clear that you we are either overriding
what with what and then removing a method. But as lukas mentionned, we
may be stepping out of line here...

>  regards,
>  Lukas
>
>
>
>  --
>  PHP Internals - PHP Runtime Development Mailing List
>  To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
David,
Re-read what you are replying.