Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35740
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error)
Cc: Marcus Boerger <helly@php.net>,
 php@stefan-marr.de,
 Evert|Rooftop <evert@rooftopsolutions.nl>,
 Stanislav Malyshev <stas@zend.com>,
 internals@lists.php.net
Message-ID: <9B13D031-8116-4A06-9D22-D221396C6F28@pooteeweet.org>
To: Gregory Beaver <greg@chiaraquartet.net>
In-Reply-To: <47BF4D31.2040700@chiaraquartet.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Sat, 23 Feb 2008 01:46:57 +0100
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>
X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information
X-backendmedia-com-MailScanner: Found to be clean
X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=0.133, required 6, AWL 0.03, RDNS_DYNAMIC 0.10)
X-backendmedia-com-MailScanner-From: mls@pooteeweet.org
X-Spam-Status: No
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 22.02.2008, at 23:31, Gregory Beaver wrote:

> 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'}()"

Ah ok, I thought that trait2::a was the only way to access the trait2  
a() method. Ok then its not as problematic. However I do not really  
like that syntax much. Like I said I also do not like the use of the  
word "private" in this context. I find it totally confusing, since its  
not private in the PPP sense. And like I also said before, I am not  
convinced that traits belong outside of the curly brackets next to the  
class name and the interface the class may implement. That would make  
it appear like the trait defines the "type" of the class, which it  
should not.

So I am still of the opinion that by default all properties/methods  
should be imported as encapsulated units and the developer can decide  
which parts of the trait should become visibile to the trait using  
class.

regards,
Lukas