Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35719
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: <47BE6413.6090507@chiaraquartet.net>
Date: Thu, 21 Feb 2008 23:56:35 -0600
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Christian Schneider <cschneid@cschneid.com>
CC: internals Mailing List <internals@lists.php.net>
References: <47BD207C.2080905@chiaraquartet.net> <47BD928E.8080006@cschneid.com>
In-Reply-To: <47BD928E.8080006@cschneid.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: Trait aliasing syntax suggestions
From: greg@chiaraquartet.net (Gregory Beaver)

Christian Schneider wrote:

> So my favourite solution (apart from allowing include in class
> definitions ;-)) would be
> trait foo { ... }
> ...
> class B
> {
> 	trait foo;		# All functions from foo
> 	trait bar(a);		# Only function a from bar
> 	trait qux(not b);	# Everythign but function b
> 	trait quux(c as d);	# Include c but rename it to d
> 	trait quuux(not b, c as d);	# Combination of the above
> }

I could live with most of this as well.

"trait bar(a);" is really confusing - it looks like a function call and
is not nearly as clear as the other options.  It's unlikely to be
necessary since a trait should really only have a few functions in it
anyways.

> Note: The inclusion of specific functions acts as if a "not *" (while *
> doesn't really need to be implemented neither for inclusion nor
> exclusion IMHO) was given first.
> 
> Another detail: The implementation of the parser changes should still
> allow a class or function called "trait", i.e. "trait" should only be a
> keyword at specific positions in the source to avoid unneccesary BC
> breaks. The current patch has this BC problem.

This is not possible to implement, having tried to do a similar thing
for 'import' and 'namespace.'  The reason is that we can encounter a
classname at any point thanks to "classname::whatever" syntax, so it
slows the lexer down a bit in that for every T_TRAIT we would have to
check to see if the next 2 characters are ::, and makes the lexer
uber-complicated.  It's a big mess.

Greg