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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
