On Thu, 21 Feb 2008, Stefan Marr wrote:
> jvlad schrieb:
> > in other words, why to introduce such a new thing as trait instead of using
> > classes and trait'ing them?
>
> I've introduced it as a separate notion from classes to avoid misconception
> and problems occurring from conflicting propert
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, havi
Hi,
Christian Schneider schrieb:
I can see two
use cases for aliasing:
> 1) An interface uses a different name than the
trait implements. Not sure that's a software design problem trait should
try to solve.
Well, no, aliasing shouldn't be used to achieve this, think it would be
better to add
Gregory Beaver schrieb:
Christian Schneider wrote:
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
On 22.02.2008, at 06:56, Gregory Beaver wrote:
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
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
Hi,
jvlad schrieb:
Why would this create any problems? Say, you have class B that extends class
A and both do define one method and one property under the same names. Will
this create a problem? No. It's because there are rules that clearly
describe how it works (method and property will be ov
"Stefan Marr" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> jvlad schrieb:
>> in other words, why to introduce such a new thing as trait instead of
>> using classes and trait'ing them?
> I've introduced it as a separate notion from classes to avoid
> misconception and pr
Hi,
jvlad schrieb:
in other words, why to introduce such a new thing as trait instead of using
classes and trait'ing them?
I've introduced it as a separate notion from classes to avoid
misconception and problems occurring from conflicting properties and
constant definitions.
Your example dem
Hi,
what's about sample below?
in other words, why to introduce such a new thing as trait instead of using
classes and trait'ing them?
just my two cents.
-j
"Gregory Beaver" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> Here is a slightly clearer syntax for trait in
Gregory Beaver wrote:
> Here is a slightly clearer syntax for trait instantiation and for
> aliasing/removing method names from traits:
>
> trait foo
...
>
> class B
> {
> trait foo {unset bing, bar as bing};
> trait bar;
> }
I like the approach to reuse identifiers (trait both in dec
[snip...]
>
> class A
> {
> trait foo;
> }
>
> class B
> {
> trait foo {unset bing, bar as bing};
> trait bar;
> }
> ?>
>
[snip...]
As long as we're discussing syntax - I rather like
class A
{
attach foo;
}
class B
{
attach foo {hide bing, bar as bing};
attach bar
12 matches
Mail list logo
