Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35730
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.146.183 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=npBgZoZVqo3sQnA6bb/HqGhZ2hOVVR1LYFiI3OI+/3jQYAUs6xMAh6elOewjdDywxwAGWiSBpB/dxCva9RjjZSbTCUm4yYin843SxKgFgTfTsvX42qLUZwPuvvVBlxY2c1+NJS3nkDrcO8Z4LHFVeYeBcdxNagDgla+vwV3Y174=
Message-ID: <b5f7bf6c0802220733h1ca2bf6frb18eb4b61540d666@mail.gmail.com>
Date: Fri, 22 Feb 2008 10:33:12 -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: <b5f7bf6c0802220732n142f409dq85845b8561b9fe9c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <001c01c87264$3c01b4e0$b4051ea0$@de>
	 <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>
	 <b5f7bf6c0802220732n142f409dq85845b8561b9fe9c@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: davidc@php.net ("David Coallier")

On Fri, Feb 22, 2008 at 10:32 AM, David Coallier <davidc@php.net> wrote:
>
> 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;

It is of course

       remove One::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.
>



-- 
David,
Re-read what you are replying.