Re: Trait aliasing syntax suggestions

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