Fantastic. Nice RFC, nice explanation, nice design - I love it.

Can I

+1

already? :)

David

Am 18.02.2008 um 20:27 schrieb php@stefan-marr.de <php@stefan-
marr.de>:

Hi,

during last six months I've studied a language construct called
Traits.
It is a construct to allow fine-grained code reuse and in my opinon
this would be a nice feature for PHP, which I did like to propose
here.
The following RFC deals with the questions what Traits are, how they
are
used, why they are usefull and how they do look like in PHP.
A patch implementing this new language construct is available, too.

Thank you for your attention and I'm looking forward to hear your
comments
:)

Kind Regards
Stefan

Request for Comments: Traits for PHP

:HTML: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html

... contents::

This RFC will discuss at first the motivation for Traits describing  
the
rationals
and presenting a short real world use case. The main part will  
describe the
concept of Traits in detail using the syntax for Traits implemented  
in a
patch
which is part of this proposal. In the end, the URL of the patch and
additional resources about Traits are given.

Introduction
============

*Traits* is a mechanism for code reuse in single inheritance  
languages such
as PHP. A Trait is intended to reduce some limitations of single  
inheritance
by enabeling a developer to reuse sets of methods freely in several
independent
classes living in different class hierarchies.
The semantics of the combination of Traits and classes is defined in  
a way,
which reduces complexity and avoids the typical problems associated  
with
multiple
inheritance and Mixins.

They are recognized for their potential in supporting better  
composition
and reuse, hence their integration in newer versions of languages
such as Perl 6, Squeak, Scala, Slate and Fortress.
Traits have also been ported to Java and C#.


Why do we need Traits?
----------------------

Code reuse is one of the main goals that object-oriented languages  
try to
achieve
with inheritance. Unfortunately, single inheritance often forces the
developer
to take a decision in favor for either code reuse *or* conceptual  
clean
class
hierarchies. To achieve code reuse, methods have either to be  
duplicated or
to be moved near the root of the class hierarchy, but this hampers
understandability and maintainability of code.

To circumvent this problems multiple inheritance and Mixins have been
invented.
But both of them are complex and hard to understand. PHP5
has been explicitly designed with the clean and successful model of  
Java in
mind: single inheritance, but multiple interfaces. This decision has  
been
taken
to avoid the known problems of for example C++.
Traits have been invented to avoid those problems, too. They enable  
designer
to build
conceptually clean class hierarchies without the need to consider  
code reuse
or
complexity problems, but focusing on the real problem domain and
maintainability
instead.

Traits: A Mechanism for Fine-grained Reuse
==========================================

A Trait is a unit of reuse much like a class, but only intended to  
group
functionality in a fine-grained and consistent way. It is not  
possible to
instantiate a Trait on its own. It is an addition to traditional  
inheritance
and enables horizontal composition of behavior.

The following code illustrates the current implementation of an  
extended
version of the PHP reflection API which provides detailed access to  
doc
comment
blocks.

ReflectionMethod and ReflectionFunction are classes from the  
reflection API
and
have to be extended with exactly the same code. In some situations it
would be possible to add a common base class, but in this case it is
impossible, because the extended classes are not under our control,  
i.e.,
they
are implemented in third party code or even in C, like it is the  
case here.
::

<?php
class ezcReflectionMethod extends ReflectionMethod {
  /* ... */
  function getReturnType() { /*1*/ }
  function getReturnDescription() { /*2*/ }
  /* ... */
}

class ezcReflectionFunction extends ReflectionFunction {
  /* ... */
  function getReturnType() { /*1*/ }
  function getReturnDescription() { /*2*/ }
  /* ... */
}
?>

With Traits it is possible to refactor this redundant code out.
::

<?php
trait ezcReflectionReturnInfo {
  function getReturnType() { /*1*/ }
  function getReturnDescription() { /*2*/ }
}

class ezcReflectionMethod extends ReflectionMethod {
  use ezcReflectionReturnInfo;
  /* ... */
}

class ezcReflectionFunction extends ReflectionFunction {
  use ezcReflectionReturnInfo;
  /* ... */
}
?>

This is just a small example of what Traits are useful for.
The next sections will discuss on more advanced techniques and  
describe how
the
current implementation of Traits for PHP works.

The Flattening Property
-----------------------

As already mentioned, multiple inheritance and Mixins are complex
mechanisms.
Traits are an alternative which have been designed to impose no
additional semantics on classes. Traits are only entities of the  
literal
code
written in your source files. There is no notion about Traits at  
runtime.
They are used to group methods and reuse code and are totally  
flattened
into the classes composed from them. It is almost like a language  
supported
and
failsafe copy'n'paste mechanism to build classes.

Precedence Order
""""""""""""""""

Flattening is achieved by applying some simple rules on the  
composition
mechanism. Instead of implementing a fancy and awkward algorithm to  
solve
problems, the entire control about the composition is left in the  
hand of
the
developer and fits nicely into the known inheritance model of PHP.
The following examples illustrate the semantics of Traits and their  
relation
to methods defined in classes.
::

<?php
class Base {
  public function sayHello() {
    echo 'Hello ';
  }
}

trait SayWorld {
  public function sayHello() {
    parent::sayHello();
    echo 'World!';
  }
}

class MyHelloWorld extends Base {
  use SayWorld;
}

$o = new MyHelloWorld();
$o->sayHello(); // echos Hello World!
?>

As shown in the above code, an inherited method from a base class is
overridden
by the method inserted into ``MyHelloWorld`` from the ``SayWorld``  
Trait.
The behavior is the same for methods defined in the ``MyHelloWorld``  
class.
The precedence order is that methods from the current class override  
Trait
methods,
which in return override methods from the base class.
::

<?php
trait HelloWorld {
  public function sayHello() {
    echo 'Hello World!';
  }
}

class TheWorldIsNotEnough {
  use HelloWorld;
  public function sayHello() {
    echo 'Hello Universe!';
  }
}

$o = new TheWorldIsNotEnough();
$o->sayHello(); // echos Hello Universe!
?>

Multiple Traits Usage
"""""""""""""""""""""

To keep things simple in the beginning, there has only one Trait  
being used
at
a time, but obviously a class could use multiple Traits at the same  
time.
::

<?php
trait Hello {
  public function sayHello() {
    echo 'Hello ';
  }
}

trait World {
  public function sayWorld() {
    echo ' World';
  }
}

class MyHelloWorld {
  use Hello;
  use World;
  public function sayExclamationMark() {
    echo '!';
  }
}

$o = new MyHelloWorld();
$o->sayHello();
$o->sayWorld();
$o->sayExclamationMark();
// Results eventually in: Hello World!

Conflict Resolution
"""""""""""""""""""

But now a problem will occur, if different Traits provide methods  
with the
same name.
::

<?php
trait A {
  public function smallTalk() {
    echo 'a';
  }
  public function bigTalk() {
    echo 'A';
  }
}

trait B {
  public function smallTalk() {
    echo 'b';
  }
  public function bigTalk() {
    echo 'B';
  }
}
?>

Both classes have to be used in a class named ``Talker``. Multiple
inheritance
and Mixins define an algorithm to resolve this conflict. Traits don't.
Conflicts
aren't solved implicitly by any kind of precedence. Instead, to avoid
implicit
complexity, the developer has full control over class composition.
::

<?php
class Talker {
  use A;
  use B;
}
?>

In case of the above definition of ``Talker``, PHP will show a  
notice that
there
have been conflicts and name the methods ``smallTalk()`` and  
``bigTalk()``
as the reason of this conflict. Therefore, neither of the given
implementations
will be available in the class.

Instead, the developer can exactly define which methods are used and  
how the
conflict is resolved.
::

<?php
class Talker {
  use A { !smallTalk }
  use B { !bigTalk }
}
?>

This definition will result in the exclusion of ``smallTalk()`` from  
the
Trait A
and ``bigTalk()`` from Trait B. Therefore, the resulting class  
Talker would
echo ``'b'`` for ``smallTalk()`` and ``'A'`` for ``bigTalk().``
But simple exclusion of methods is not the best choice for all  
situations.
::

<?php
class Talker {
  use A { !smallTalk }
  use B { !bigTalk, talk => bigTalk }
}
?>

Beside the exclusion an alias operation is available, too. This alias
operation, notated like a ``key => value`` for arrays even has a  
similar
semantics like the array notation. The definition ``talk => bigTalk``
lets the new name ``talk`` refer to the method body of ``bigTalk``
of the Trait B. The resulting ``Talker`` class will consist of  
following
three methods:

* ``bigTalk() { echo 'A'; }``
* ``smallTalk() { echo 'b'; }``
* ``talk() { echo 'B'; }``

Since the alias operation adds a new name to an existing method  
body, the
``bigTalk`` method still has to be excluded. Otherwise, PHP would  
print
a notice that two methods from Traits have a conflict and are  
excluded.
Aliasing is not renaming and references in methods to a given method  
name
aren't changed either. On the first look this may sound strange, but  
it
provides the opportunity to build Traits and even hierarchies of  
Traits
which
fit together very well.

Traits Composed from Traits
"""""""""""""""""""""""""""

Not explicitly mentioned jet, but implied by the flattening property  
is the
composition of Traits from Traits.
Since Traits are fully flattened away at compile time it is possible  
to use
Traits to compose Traits without any additional impact on the  
semantics.
The following code illustrates this::

<?php
trait Hello {
  public function sayHello() {
    echo 'Hello ';
  }
}

trait World {
  public function sayWorld() {
    echo 'World!';
  }
}

trait HelloWorld {
  use Hello;
  use World;
}

class MyHelloWorld {
  use HelloWorld;
}

$o = new MyHelloWorld();
$o->sayHello();
$o->sayWorld();
// Results eventually in: Hello World!
?>

Traits itself can take part in arbitrary compositions, but Traits  
are not
part
of the inheritance tree i.e., it is not possible to inherit from a  
Trait to
avoid confusion and misuse of Traits.

Traits Semantics Summarized
---------------------------

1. Traits do not add runtime semantics, they only take part in the  
process
of
  building a class.
2. Traits integrate into the precedence order of method overriding.
3. To avoid complexity, conflicts between Trait methods have to be  
solved
  explicitly. Otherwise a notice is generated and the conflicting  
methods
  are excluded.
4. Specific methods can be excluded from a composition to handle  
conflicts.
5. Aliases can be defined for methods to enable reuse of conflicting
methods.
6. Traits can be composed from Traits.

As a result of this semantics, at runtime, classes build using  
Traits are
not distinguishable
from classes not using Traits but traditional code duplication  
instead.
Semantics of ``parent`` and ``$this`` hasn't changed, too. Used in a  
Trait
method, they behave exactly the same as if the method has been  
defined in
the
class directly.

Visibility and Interfaces
-------------------------

Visibility modifiers have not been discussed so far. Since Traits  
are meant
as
units of reuse, modifiers should be changeable easily in the context  
of a
composed class. Therefore, the aliasing operation is able to change  
the
visibility modifier of a method, too.
::

<?php
trait HelloWorld {
  public function sayHello() {
    echo 'Hello World!';
  }
}

class MyClass1 {
  use HelloWorld { protected sayHello }
}

class MyClass2 {
  use HelloWorld { private doHelloWorld => sayHello }
}
?>

The abstract and final modifiers are supported, too. Abstract  
methods in
Traits are commonly used to define requirements a Trait needs to have
implemented by a class. The static modifier is not supported,  
because it
would
change the methods semantics and references to ``$this`` would break.

Another important feature of PHP is the support of interfaces. A  
often used
metaphor to describe Traits is *Traits are interfaces with  
implementation*.
Traits can be utilized to provide the implementation for a specific
interface
and since an interface is a guarantee that some methods are  
available it
fits
in the concept of Traits which provides those methods very well.

To underpin this relationship, it is possible to declare that a Trait
implements an interface like this::

<?php
interface IHello {
  public function sayHello();
}

trait SayHello implements IHello {
  public function sayHello() {
    echo 'Hello World!';
  }
}

class MyHelloWorld {
  use SayHello;
}

$o = new MyHelloWorld();
var_dump($o instanceof IHello);  // bool(true)

If a Trait implements an interface, this definition is propagated to  
the
class
using the Trait. Therefore, it is possible to provide  
implementations for an
interface
and reuse them in different classes.

Proposal and Patch
==================

This Request for Comments proposes a new language feature for PHP  
named
Traits.
Traits are a nice approach to enhance the capabilities to design  
conceptual
consistent class hierarchies and avoid code duplication.

The patch against the PHP_5_2 branch is available at
http://toolslave.net/snapshots/traits/traits.patch
The written test cases are located here:
http://toolslave.net/snapshots/traits/traits-tests.zip
Additionally, the SVN repo used for developing this patch is located  
at
https://instantsvc.svn.sourceforge.net/svnroot/instantsvc/branches/php-exten
sion/traits-php/

Alternative Syntax Proposals
----------------------------

This section collects proposals for alternative Traits syntaxes.

Traits Use Definition in the Class Header
"""""""""""""""""""""""""""""""""""""""""

Instead of declaring the Trait composition in the class body, it  
could be
defined in the class prologue like this::

<?php
trait Hello {
  public function sayHello() {}
}


class MyHelloWorld extends BaseClass
  uses Hello (hello => sayHello, !sayHello)
{
  public function foo() {}
}
?>

The drawback of this notation is the implied notation of Traits as  
some kind
of
a type changing construct. Since they do not influence the type as  
their
major
feature, this notion would be misleading. Furthermore, this notation  
seams
to
have readability problems. Complex compositions are not as clearly  
arranged
as
they are with the *In-Body* notation.
A patch implementing this notation is available at:
http://toolslave.net/snapshots/traits/traits-head-syntax.patch


More about Traits
-----------------

As already mentioned, Traits is not a totally new concept, but the  
semantics
used in this proposal has been fully defined at first in 2003. For
scientific
information and papers about Traits
http://www.iam.unibe.ch/~scg/Research/Traits/
is a good starting point. Since it isn't a purely academic concepts,  
there
are
already languages supporting Traits out there. Squeak, Perl6, Scala,  
Slate,
Fortress and even for C#/Rotor implementation are available.

A detailed technical report has been published at
http://www.iam.unibe.ch/~scg/Archive/Papers/Duca06bTOPLASTraits.pdf
It explains Traits and gives some formal proves about the soundness of
Traits, too.

Last but not least, in this Phd thesis
http://www.iam.unibe.ch/~scg/Archive/PhD/schaerli-phd.pdf
two case studies have been publish illustrating the benefits Traits  
are
providing.

<?php
trait ezcReflectionReturnInfo {
function getReturnType() { /1/ }
function getReturnDescription() { /2/ }
}

class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;

So it's just like an include for a re-used body of 'class' code.

Hmmmm.

Why not just allow 'include' here instead?

:-)

Forgive me if I'm missing something subtle/complex here, but I wonder
if a Trait is really the "right answer"...

Yes, the ability to add/exclude specific functions from two Traits is
"gone" with a simple 'include'... But so is the complexity of yet
another language construct...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?

php@stefan-marr.de schrieb:

The following RFC deals with the questions what Traits are, how they are
used, why they are usefull and how they do look like in PHP.

Thank you, Stefan, for your thorough RFC.

A patch implementing this new language construct is available, too.

I tested an earlier version of the patch back in December when I read
(and commented on) the RFC.

I like the idea of Traits and your implementation for PHP and would just
love to see this make its way into PHP.

--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Hi,

during last six months I've studied a language construct called Traits.
It is a construct to allow fine-grained code reuse and in my opinon
this would be a nice feature for PHP, which I did like to propose here.
The following RFC deals with the questions what Traits are, how they are
used, why they are usefull and how they do look like in PHP.
A patch implementing this new language construct is available, too.

Thank you for your attention and I'm looking forward to hear your comments
:)

Kind Regards
Stefan

Request for Comments: Traits for PHP

:HTML: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html

... contents::

This RFC will discuss at first the motivation for Traits describing the
rationals
and presenting a short real world use case. The main part will describe the
concept of Traits in detail using the syntax for Traits implemented in a
patch
which is part of this proposal. In the end, the URL of the patch and
additional resources about Traits are given.

Introduction
============

*Traits* is a mechanism for code reuse in single inheritance languages such
as PHP. A Trait is intended to reduce some limitations of single inheritance
by enabeling a developer to reuse sets of methods freely in several
independent
classes living in different class hierarchies.
The semantics of the combination of Traits and classes is defined in a way,
which reduces complexity and avoids the typical problems associated with
multiple
inheritance and Mixins.

They are recognized for their potential in supporting better composition
and reuse, hence their integration in newer versions of languages
such as Perl 6, Squeak, Scala, Slate and Fortress.
Traits have also been ported to Java and C#.


Why do we need Traits?
----------------------

Code reuse is one of the main goals that object-oriented languages try to
achieve
with inheritance. Unfortunately, single inheritance often forces the
developer
to take a decision in favor for either code reuse *or* conceptual clean
class
hierarchies. To achieve code reuse, methods have either to be duplicated or
to be moved near the root of the class hierarchy, but this hampers
understandability and maintainability of code.

To circumvent this problems multiple inheritance and Mixins have been
invented.
But both of them are complex and hard to understand. PHP5
has been explicitly designed with the clean and successful model of Java in
mind: single inheritance, but multiple interfaces. This decision has been
taken
to avoid the known problems of for example C++.
Traits have been invented to avoid those problems, too. They enable designer
to build
conceptually clean class hierarchies without the need to consider code reuse
or
complexity problems, but focusing on the real problem domain and
maintainability
instead.

Traits: A Mechanism for Fine-grained Reuse
==========================================

A Trait is a unit of reuse much like a class, but only intended to group
functionality in a fine-grained and consistent way. It is not possible to
instantiate a Trait on its own. It is an addition to traditional inheritance
and enables horizontal composition of behavior.

The following code illustrates the current implementation of an extended
version of the PHP reflection API which provides detailed access to doc
comment
blocks.

ReflectionMethod and ReflectionFunction are classes from the reflection API
and
have to be extended with exactly the same code. In some situations it
would be possible to add a common base class, but in this case it is
impossible, because the extended classes are not under our control, i.e.,
they
are implemented in third party code or even in C, like it is the case here.
::

 <?php
 class ezcReflectionMethod extends ReflectionMethod {
   /* ... */
   function getReturnType() { /*1*/ }
   function getReturnDescription() { /*2*/ }
   /* ... */
 }

 class ezcReflectionFunction extends ReflectionFunction {
   /* ... */
   function getReturnType() { /*1*/ }
   function getReturnDescription() { /*2*/ }
   /* ... */
 }
 ?>

With Traits it is possible to refactor this redundant code out.
::

 <?php
 trait ezcReflectionReturnInfo {
   function getReturnType() { /*1*/ }
   function getReturnDescription() { /*2*/ }
 }

 class ezcReflectionMethod extends ReflectionMethod {
   use ezcReflectionReturnInfo;
   /* ... */
 }

 class ezcReflectionFunction extends ReflectionFunction {
   use ezcReflectionReturnInfo;
   /* ... */
 }
 ?>

This is just a small example of what Traits are useful for.
The next sections will discuss on more advanced techniques and describe how
the
current implementation of Traits for PHP works.

The Flattening Property
-----------------------

As already mentioned, multiple inheritance and Mixins are complex
mechanisms.
Traits are an alternative which have been designed to impose no
additional semantics on classes. Traits are only entities of the literal
code
written in your source files. There is no notion about Traits at runtime.
They are used to group methods and reuse code and are totally flattened
into the classes composed from them. It is almost like a language supported
and
failsafe copy'n'paste mechanism to build classes.

Precedence Order
""""""""""""""""

Flattening is achieved by applying some simple rules on the composition
mechanism. Instead of implementing a fancy and awkward algorithm to solve
problems, the entire control about the composition is left in the hand of
the
developer and fits nicely into the known inheritance model of PHP.
The following examples illustrate the semantics of Traits and their relation
to methods defined in classes.
::

 <?php
 class Base {
   public function sayHello() {
     echo 'Hello ';
   }
 }

 trait SayWorld {
   public function sayHello() {
     parent::sayHello();
     echo 'World!';
   }
 }

 class MyHelloWorld extends Base {
   use SayWorld;
 }

 $o = new MyHelloWorld();
 $o->sayHello(); // echos Hello World!
 ?>

As shown in the above code, an inherited method from a base class is
overridden
by the method inserted into ``MyHelloWorld`` from the ``SayWorld`` Trait.
The behavior is the same for methods defined in the ``MyHelloWorld`` class.
The precedence order is that methods from the current class override Trait
methods,
which in return override methods from the base class.
::

 <?php
 trait HelloWorld {
   public function sayHello() {
     echo 'Hello World!';
   }
 }

 class TheWorldIsNotEnough {
   use HelloWorld;
   public function sayHello() {
     echo 'Hello Universe!';
   }
 }

 $o = new TheWorldIsNotEnough();
 $o->sayHello(); // echos Hello Universe!
 ?>

Multiple Traits Usage
"""""""""""""""""""""

To keep things simple in the beginning, there has only one Trait being used
at
a time, but obviously a class could use multiple Traits at the same time.
::

 <?php
 trait Hello {
   public function sayHello() {
     echo 'Hello ';
   }
 }

 trait World {
   public function sayWorld() {
     echo ' World';
   }
 }

 class MyHelloWorld {
   use Hello;
   use World;
   public function sayExclamationMark() {
     echo '!';
   }
 }

 $o = new MyHelloWorld();
 $o->sayHello();
 $o->sayWorld();
 $o->sayExclamationMark();
 // Results eventually in: Hello World!

Conflict Resolution
"""""""""""""""""""

But now a problem will occur, if different Traits provide methods with the
same name.
::

 <?php
 trait A {
   public function smallTalk() {
     echo 'a';
   }
   public function bigTalk() {
     echo 'A';
   }
 }

 trait B {
   public function smallTalk() {
     echo 'b';
   }
   public function bigTalk() {
     echo 'B';
   }
 }
 ?>

Both classes have to be used in a class named ``Talker``. Multiple
inheritance
and Mixins define an algorithm to resolve this conflict. Traits don't.
Conflicts
aren't solved implicitly by any kind of precedence. Instead, to avoid
implicit
complexity, the developer has full control over class composition.
::

 <?php
 class Talker {
   use A;
   use B;
 }
 ?>

In case of the above definition of ``Talker``, PHP will show a notice that
there
have been conflicts and name the methods ``smallTalk()`` and ``bigTalk()``
as the reason of this conflict. Therefore, neither of the given
implementations
will be available in the class.

Instead, the developer can exactly define which methods are used and how the
conflict is resolved.
::

 <?php
 class Talker {
   use A { !smallTalk }
   use B { !bigTalk }
 }
 ?>

This definition will result in the exclusion of ``smallTalk()`` from the
Trait A
and ``bigTalk()`` from Trait B. Therefore, the resulting class Talker would
echo ``'b'`` for ``smallTalk()`` and ``'A'`` for ``bigTalk().``
But simple exclusion of methods is not the best choice for all situations.
::

 <?php
 class Talker {
   use A { !smallTalk }
   use B { !bigTalk, talk => bigTalk }
 }
 ?>

Beside the exclusion an alias operation is available, too. This alias
operation, notated like a ``key => value`` for arrays even has a similar
semantics like the array notation. The definition ``talk => bigTalk``
lets the new name ``talk`` refer to the method body of ``bigTalk``
of the Trait B. The resulting ``Talker`` class will consist of following
three methods:

* ``bigTalk() { echo 'A'; }``
* ``smallTalk() { echo 'b'; }``
* ``talk() { echo 'B'; }``

Since the alias operation adds a new name to an existing method body, the
``bigTalk`` method still has to be excluded. Otherwise, PHP would print
a notice that two methods from Traits have a conflict and are excluded.
Aliasing is not renaming and references in methods to a given method name
aren't changed either. On the first look this may sound strange, but it
provides the opportunity to build Traits and even hierarchies of Traits
which
fit together very well.

Traits Composed from Traits
"""""""""""""""""""""""""""

Not explicitly mentioned jet, but implied by the flattening property is the
composition of Traits from Traits.
Since Traits are fully flattened away at compile time it is possible to use
Traits to compose Traits without any additional impact on the semantics.
The following code illustrates this::

 <?php
 trait Hello {
   public function sayHello() {
     echo 'Hello ';
   }
 }

 trait World {
   public function sayWorld() {
     echo 'World!';
   }
 }

 trait HelloWorld {
   use Hello;
   use World;
 }

 class MyHelloWorld {
   use HelloWorld;
 }

 $o = new MyHelloWorld();
 $o->sayHello();
 $o->sayWorld();
 // Results eventually in: Hello World!
 ?>

Traits itself can take part in arbitrary compositions, but Traits are not
part
of the inheritance tree i.e., it is not possible to inherit from a Trait to
avoid confusion and misuse of Traits.

Traits Semantics Summarized
---------------------------

1. Traits do not add runtime semantics, they only take part in the process
of
   building a class.
2. Traits integrate into the precedence order of method overriding.
3. To avoid complexity, conflicts between Trait methods have to be solved
   explicitly. Otherwise a notice is generated and the conflicting methods
   are excluded.
4. Specific methods can be excluded from a composition to handle conflicts.
5. Aliases can be defined for methods to enable reuse of conflicting
methods.
6. Traits can be composed from Traits.

As a result of this semantics, at runtime, classes build using Traits are
not distinguishable
from classes not using Traits but traditional code duplication instead.
Semantics of ``parent`` and ``$this`` hasn't changed, too. Used in a Trait
method, they behave exactly the same as if the method has been defined in
the
class directly.

Visibility and Interfaces
-------------------------

Visibility modifiers have not been discussed so far. Since Traits are meant
as
units of reuse, modifiers should be changeable easily in the context of a
composed class. Therefore, the aliasing operation is able to change the
visibility modifier of a method, too.
::

 <?php
 trait HelloWorld {
   public function sayHello() {
     echo 'Hello World!';
   }
 }

 class MyClass1 {
   use HelloWorld { protected sayHello }
 }

 class MyClass2 {
   use HelloWorld { private doHelloWorld => sayHello }
 }
 ?>

The abstract and final modifiers are supported, too. Abstract methods in
Traits are commonly used to define requirements a Trait needs to have
implemented by a class. The static modifier is not supported, because it
would
change the methods semantics and references to ``$this`` would break.

Another important feature of PHP is the support of interfaces. A often used
metaphor to describe Traits is *Traits are interfaces with implementation*.
Traits can be utilized to provide the implementation for a specific
interface
and since an interface is a guarantee that some methods are available it
fits
in the concept of Traits which provides those methods very well.

To underpin this relationship, it is possible to declare that a Trait
implements an interface like this::

 <?php
 interface IHello {
   public function sayHello();
 }

 trait SayHello implements IHello {
   public function sayHello() {
     echo 'Hello World!';
   }
 }

 class MyHelloWorld {
   use SayHello;
 }

 $o = new MyHelloWorld();
 var_dump($o instanceof IHello);  // bool(true)

If a Trait implements an interface, this definition is propagated to the
class
using the Trait. Therefore, it is possible to provide implementations for an
interface
and reuse them in different classes.

Proposal and Patch
==================

This Request for Comments proposes a new language feature for PHP named
Traits.
Traits are a nice approach to enhance the capabilities to design conceptual
consistent class hierarchies and avoid code duplication.

The patch against the PHP_5_2 branch is available at
http://toolslave.net/snapshots/traits/traits.patch
The written test cases are located here:
http://toolslave.net/snapshots/traits/traits-tests.zip
Additionally, the SVN repo used for developing this patch is located at
https://instantsvc.svn.sourceforge.net/svnroot/instantsvc/branches/php-exten
sion/traits-php/

Alternative Syntax Proposals
----------------------------

This section collects proposals for alternative Traits syntaxes.

Traits Use Definition in the Class Header
"""""""""""""""""""""""""""""""""""""""""

Instead of declaring the Trait composition in the class body, it could be
defined in the class prologue like this::

 <?php
 trait Hello {
   public function sayHello() {}
 }


 class MyHelloWorld extends BaseClass
   uses Hello (hello => sayHello, !sayHello)
 {
   public function foo() {}
 }
 ?>

The drawback of this notation is the implied notation of Traits as some kind
of
a type changing construct. Since they do not influence the type as their
major
feature, this notion would be misleading. Furthermore, this notation seams
to
have readability problems. Complex compositions are not as clearly arranged
as
they are with the *In-Body* notation.
A patch implementing this notation is available at:
http://toolslave.net/snapshots/traits/traits-head-syntax.patch


More about Traits
-----------------

As already mentioned, Traits is not a totally new concept, but the semantics
used in this proposal has been fully defined at first in 2003. For
scientific
information and papers about Traits
http://www.iam.unibe.ch/~scg/Research/Traits/
is a good starting point. Since it isn't a purely academic concepts, there
are
already languages supporting Traits out there. Squeak, Perl6, Scala, Slate,
Fortress and even for C#/Rotor implementation are available.

A detailed technical report has been published at
http://www.iam.unibe.ch/~scg/Archive/Papers/Duca06bTOPLASTraits.pdf
It explains Traits and gives some formal proves about the soundness of
Traits, too.

Last but not least, in this Phd thesis
http://www.iam.unibe.ch/~scg/Archive/PhD/schaerli-phd.pdf
two case studies have been publish illustrating the benefits Traits are
providing.

From a userland perspective (i.e. not knowing the internals impact),
this looks like a great feature which treats the userland developer
with a bit of respect.

It allows me to take a class and add some addition functionality to it
without subclassing.
Conflicts are MY responsibility to solve.
No magic.

From a userland developer, +1.

A question (and again, no idea on feasibility, internals, etc.).

The above proposal covers adding/overriding internal methods with
external ones. Is it possible to also include additional properties?

If not, then you would have to override the constructor method (this
could be demoted to documentation rather than code then I suppose).

--

Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

Hi,

during last six months I've studied a language construct called Traits.
It is a construct to allow fine-grained code reuse and in my opinon
this would be a nice feature for PHP, which I did like to propose here.
The following RFC deals with the questions what Traits are, how they are
used, why they are usefull and how they do look like in PHP.
A patch implementing this new language construct is available, too.

Thank you for your attention and I'm looking forward to hear your comments
:)

Kind Regards
Stefan

I know this is in the bike-shed department, but the following syntax
doesn't look very PHP to me:
use B { !bigTalk, talk => bigTalk }

Could we separate exclusions from aliases somehow?

--
troels

Hello php,

looks good to me. See more detailed thoughts in separate mail resonses.
The biggest issue I see is finding a syntax everyone likes.

Personally I like everything but one tiny piece, that is you do '!method'
to ignore a method from a trait. Since renaming happens in a php array like
style I would prefer to have that approach apply for ignoring methods as
well. The way to do that imo is 'method=>false' or 'method=>NULL' which both
should be obvious to PHP programmers that heard about Traits.

Other than that I'd even appriciate it, if we could get this for 5.3. I mean
come on guys it is ready and a very nice solution to the code reuse problem.

marcus

Monday, February 18, 2008, 8:27:00 PM, you wrote:

Hi,

during last six months I've studied a language construct called Traits.
It is a construct to allow fine-grained code reuse and in my opinon
this would be a nice feature for PHP, which I did like to propose here.
The following RFC deals with the questions what Traits are, how they are
used, why they are usefull and how they do look like in PHP.
A patch implementing this new language construct is available, too.

Thank you for your attention and I'm looking forward to hear your comments
:)

Kind Regards
Stefan

Request for Comments: Traits for PHP

:HTML: http://www.stefan-marr.de/artikel/rfc-traits-for-php.html

... contents::

This RFC will discuss at first the motivation for Traits describing the
rationals
and presenting a short real world use case. The main part will describe the
concept of Traits in detail using the syntax for Traits implemented in a
patch
which is part of this proposal. In the end, the URL of the patch and
additional resources about Traits are given.

Introduction

Traits is a mechanism for code reuse in single inheritance languages such
as PHP. A Trait is intended to reduce some limitations of single inheritance
by enabeling a developer to reuse sets of methods freely in several
independent
classes living in different class hierarchies.
The semantics of the combination of Traits and classes is defined in a way,
which reduces complexity and avoids the typical problems associated with
multiple
inheritance and Mixins.

They are recognized for their potential in supporting better composition
and reuse, hence their integration in newer versions of languages
such as Perl 6, Squeak, Scala, Slate and Fortress.
Traits have also been ported to Java and C#.

Why do we need Traits?

Code reuse is one of the main goals that object-oriented languages try to
achieve
with inheritance. Unfortunately, single inheritance often forces the
developer
to take a decision in favor for either code reuse or conceptual clean
class
hierarchies. To achieve code reuse, methods have either to be duplicated or
to be moved near the root of the class hierarchy, but this hampers
understandability and maintainability of code.

To circumvent this problems multiple inheritance and Mixins have been
invented.
But both of them are complex and hard to understand. PHP5
has been explicitly designed with the clean and successful model of Java in
mind: single inheritance, but multiple interfaces. This decision has been
taken
to avoid the known problems of for example C++.
Traits have been invented to avoid those problems, too. They enable designer
to build
conceptually clean class hierarchies without the need to consider code reuse
or
complexity problems, but focusing on the real problem domain and
maintainability
instead.

Traits: A Mechanism for Fine-grained Reuse

A Trait is a unit of reuse much like a class, but only intended to group
functionality in a fine-grained and consistent way. It is not possible to
instantiate a Trait on its own. It is an addition to traditional inheritance
and enables horizontal composition of behavior.

The following code illustrates the current implementation of an extended
version of the PHP reflection API which provides detailed access to doc
comment
blocks.

ReflectionMethod and ReflectionFunction are classes from the reflection API
and
have to be extended with exactly the same code. In some situations it
would be possible to add a common base class, but in this case it is
impossible, because the extended classes are not under our control, i.e.,
they
are implemented in third party code or even in C, like it is the case here.
::

<?php
class ezcReflectionMethod extends ReflectionMethod {
/* ... /
function getReturnType() { /1/ }
function getReturnDescription() { /2/ }
/ ... */
}

class ezcReflectionFunction extends ReflectionFunction {
/* ... /
function getReturnType() { /1/ }
function getReturnDescription() { /2/ }
/ ... */
}
?>

With Traits it is possible to refactor this redundant code out.
::

<?php
trait ezcReflectionReturnInfo {
function getReturnType() { /1/ }
function getReturnDescription() { /2/ }
}

class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
/* ... */
}

class ezcReflectionFunction extends ReflectionFunction {
use ezcReflectionReturnInfo;
/* ... */
}
?>

This is just a small example of what Traits are useful for.
The next sections will discuss on more advanced techniques and describe how
the
current implementation of Traits for PHP works.

The Flattening Property

As already mentioned, multiple inheritance and Mixins are complex
mechanisms.
Traits are an alternative which have been designed to impose no
additional semantics on classes. Traits are only entities of the literal
code
written in your source files. There is no notion about Traits at runtime.
They are used to group methods and reuse code and are totally flattened
into the classes composed from them. It is almost like a language supported
and
failsafe copy'n'paste mechanism to build classes.

Precedence Order
""""""""""""""""

Flattening is achieved by applying some simple rules on the composition
mechanism. Instead of implementing a fancy and awkward algorithm to solve
problems, the entire control about the composition is left in the hand of
the
developer and fits nicely into the known inheritance model of PHP.
The following examples illustrate the semantics of Traits and their relation
to methods defined in classes.
::

<?php
class Base {
public function sayHello() {
echo 'Hello ';
}
}

trait SayWorld {
public function sayHello() {
parent::sayHello();
echo 'World!';
}
}

class MyHelloWorld extends Base {
use SayWorld;
}

$o = new MyHelloWorld();
$o->sayHello(); // echos Hello World!
?>

As shown in the above code, an inherited method from a base class is
overridden
by the method inserted into MyHelloWorld from the SayWorld Trait.
The behavior is the same for methods defined in the MyHelloWorld class.
The precedence order is that methods from the current class override Trait
methods,
which in return override methods from the base class.
::

<?php
trait HelloWorld {
public function sayHello() {
echo 'Hello World!';
}
}

class TheWorldIsNotEnough {
use HelloWorld;
public function sayHello() {
echo 'Hello Universe!';
}
}

$o = new TheWorldIsNotEnough();
$o->sayHello(); // echos Hello Universe!
?>

Multiple Traits Usage
"""""""""""""""""""""

To keep things simple in the beginning, there has only one Trait being used
at
a time, but obviously a class could use multiple Traits at the same time.
::

<?php
trait Hello {
public function sayHello() {
echo 'Hello ';
}
}

trait World {
public function sayWorld() {
echo ' World';
}
}

class MyHelloWorld {
use Hello;
use World;
public function sayExclamationMark() {
echo '!';
}
}

$o = new MyHelloWorld();
$o->sayHello();
$o->sayWorld();
$o->sayExclamationMark();
// Results eventually in: Hello World!

Conflict Resolution
"""""""""""""""""""

But now a problem will occur, if different Traits provide methods with the
same name.
::

<?php
trait A {
public function smallTalk() {
echo 'a';
}
public function bigTalk() {
echo 'A';
}
}

trait B {
public function smallTalk() {
echo 'b';
}
public function bigTalk() {
echo 'B';
}
}
?>

Both classes have to be used in a class named Talker. Multiple
inheritance
and Mixins define an algorithm to resolve this conflict. Traits don't.
Conflicts
aren't solved implicitly by any kind of precedence. Instead, to avoid
implicit
complexity, the developer has full control over class composition.
::

<?php
class Talker {
use A;
use B;
}
?>

In case of the above definition of Talker, PHP will show a notice that
there
have been conflicts and name the methods smallTalk() and bigTalk()
as the reason of this conflict. Therefore, neither of the given
implementations
will be available in the class.

Instead, the developer can exactly define which methods are used and how the
conflict is resolved.
::

<?php
class Talker {
use A { !smallTalk }
use B { !bigTalk }
}
?>

This definition will result in the exclusion of smallTalk() from the
Trait A
and bigTalk() from Trait B. Therefore, the resulting class Talker would
echo 'b' for smallTalk() and 'A' for bigTalk().
But simple exclusion of methods is not the best choice for all situations.
::

<?php
class Talker {
use A { !smallTalk }
use B { !bigTalk, talk => bigTalk }
}
?>

Beside the exclusion an alias operation is available, too. This alias
operation, notated like a key => value for arrays even has a similar
semantics like the array notation. The definition talk => bigTalk
lets the new name talk refer to the method body of bigTalk
of the Trait B. The resulting Talker class will consist of following
three methods:

• bigTalk() { echo 'A'; }
• smallTalk() { echo 'b'; }
• talk() { echo 'B'; }

Since the alias operation adds a new name to an existing method body, the
bigTalk method still has to be excluded. Otherwise, PHP would print
a notice that two methods from Traits have a conflict and are excluded.
Aliasing is not renaming and references in methods to a given method name
aren't changed either. On the first look this may sound strange, but it
provides the opportunity to build Traits and even hierarchies of Traits
which
fit together very well.

Traits Composed from Traits
"""""""""""""""""""""""""""

Not explicitly mentioned jet, but implied by the flattening property is the
composition of Traits from Traits.
Since Traits are fully flattened away at compile time it is possible to use
Traits to compose Traits without any additional impact on the semantics.
The following code illustrates this::

<?php
trait Hello {
public function sayHello() {
echo 'Hello ';
}
}

trait World {
public function sayWorld() {
echo 'World!';
}
}

trait HelloWorld {
use Hello;
use World;
}

class MyHelloWorld {
use HelloWorld;
}

$o = new MyHelloWorld();
$o->sayHello();
$o->sayWorld();
// Results eventually in: Hello World!
?>

Traits itself can take part in arbitrary compositions, but Traits are not
part
of the inheritance tree i.e., it is not possible to inherit from a Trait to
avoid confusion and misuse of Traits.

Traits Semantics Summarized

1. Traits do not add runtime semantics, they only take part in the process
   of
   building a class.
2. Traits integrate into the precedence order of method overriding.
3. To avoid complexity, conflicts between Trait methods have to be solved
   explicitly. Otherwise a notice is generated and the conflicting methods
   are excluded.
4. Specific methods can be excluded from a composition to handle conflicts.
5. Aliases can be defined for methods to enable reuse of conflicting
   methods.
6. Traits can be composed from Traits.

As a result of this semantics, at runtime, classes build using Traits are
not distinguishable
from classes not using Traits but traditional code duplication instead.
Semantics of parent and $this hasn't changed, too. Used in a Trait
method, they behave exactly the same as if the method has been defined in
the
class directly.

Visibility and Interfaces

Visibility modifiers have not been discussed so far. Since Traits are meant
as
units of reuse, modifiers should be changeable easily in the context of a
composed class. Therefore, the aliasing operation is able to change the
visibility modifier of a method, too.
::

<?php
trait HelloWorld {
public function sayHello() {
echo 'Hello World!';
}
}

class MyClass1 {
use HelloWorld { protected sayHello }
}

class MyClass2 {
use HelloWorld { private doHelloWorld => sayHello }
}
?>

The abstract and final modifiers are supported, too. Abstract methods in
Traits are commonly used to define requirements a Trait needs to have
implemented by a class. The static modifier is not supported, because it
would
change the methods semantics and references to $this would break.

Another important feature of PHP is the support of interfaces. A often used
metaphor to describe Traits is Traits are interfaces with implementation.
Traits can be utilized to provide the implementation for a specific
interface
and since an interface is a guarantee that some methods are available it
fits
in the concept of Traits which provides those methods very well.

To underpin this relationship, it is possible to declare that a Trait
implements an interface like this::

<?php
interface IHello {
public function sayHello();
}

trait SayHello implements IHello {
public function sayHello() {
echo 'Hello World!';
}
}

class MyHelloWorld {
use SayHello;
}

$o = new MyHelloWorld();
var_dump($o instanceof IHello); // bool(true)

If a Trait implements an interface, this definition is propagated to the
class
using the Trait. Therefore, it is possible to provide implementations for an
interface
and reuse them in different classes.

Proposal and Patch

This Request for Comments proposes a new language feature for PHP named
Traits.
Traits are a nice approach to enhance the capabilities to design conceptual
consistent class hierarchies and avoid code duplication.

The patch against the PHP_5_2 branch is available at
http://toolslave.net/snapshots/traits/traits.patch
The written test cases are located here:
http://toolslave.net/snapshots/traits/traits-tests.zip
Additionally, the SVN repo used for developing this patch is located at
https://instantsvc.svn.sourceforge.net/svnroot/instantsvc/branches/php-exten
sion/traits-php/

Alternative Syntax Proposals

This section collects proposals for alternative Traits syntaxes.

Traits Use Definition in the Class Header
"""""""""""""""""""""""""""""""""""""""""

Instead of declaring the Trait composition in the class body, it could be
defined in the class prologue like this::

<?php
trait Hello {
public function sayHello() {}
}

class MyHelloWorld extends BaseClass
uses Hello (hello => sayHello, !sayHello)
{
public function foo() {}
}
?>

The drawback of this notation is the implied notation of Traits as some kind
of
a type changing construct. Since they do not influence the type as their
major
feature, this notion would be misleading. Furthermore, this notation seams
to
have readability problems. Complex compositions are not as clearly arranged
as
they are with the In-Body notation.
A patch implementing this notation is available at:
http://toolslave.net/snapshots/traits/traits-head-syntax.patch

More about Traits

As already mentioned, Traits is not a totally new concept, but the semantics
used in this proposal has been fully defined at first in 2003. For
scientific
information and papers about Traits
http://www.iam.unibe.ch/~scg/Research/Traits/
is a good starting point. Since it isn't a purely academic concepts, there
are
already languages supporting Traits out there. Squeak, Perl6, Scala, Slate,
Fortress and even for C#/Rotor implementation are available.

A detailed technical report has been published at
http://www.iam.unibe.ch/~scg/Archive/Papers/Duca06bTOPLASTraits.pdf
It explains Traits and gives some formal proves about the soundness of
Traits, too.

Last but not least, in this Phd thesis
http://www.iam.unibe.ch/~scg/Archive/PhD/schaerli-phd.pdf
two case studies have been publish illustrating the benefits Traits are
providing.

Best regards,
Marcus

Hi Stefan,

Am Montag, den 18.02.2008, 20:27 +0100 schrieb php@stefan-marr.de:
[...]

class ezcReflectionMethod extends ReflectionMethod {
use ezcReflectionReturnInfo;
/* ... */
}

I'm not sure if the use-keyword is a good idea as namespaces are already
"used". If we use "use" for traits, maybe going back to "import" for
namespaces would be the way to go.

cu, Lars

Lars Strojny
Senior Software Developer MediaVentures GmbH (http://mediaventures.de)

Hi,

Am Montag, den 18.02.2008, 20:27 +0100 schrieb php@stefan-marr.de:
[...]

To underpin this relationship, it is possible to declare that a Trait
implements an interface like this::

<?php
interface IHello {
public function sayHello();
}

trait SayHello implements IHello {
public function sayHello() {
echo 'Hello World!';
}
}

class MyHelloWorld {
use SayHello;
}

$o = new MyHelloWorld();
var_dump($o instanceof IHello); // bool(true)

We have discussed that in IRC a bit and a lot of questions remain. The
most important issue to me how to handle interface implementations in
cases where methods from the interface implementing trait are renamed in
the trait consumer class.
I would propose to not overcomplicate things here and I see no real
advantage in allowing traits to implement interfaces. I think also for
the sake of conceptual integrity separating interfaces clearly from
traits is a good idea: interfaces define structure while traits are
function buckets. A class may use traits, may implement interfaces and
may extend another class. This paradigm is pretty easy to explain to the
user.

cu, Lars

Lars Strojny
Senior Software Developer MediaVentures GmbH (http://mediaventures.de)

Hi,

Am Montag, den 18.02.2008, 20:27 +0100 schrieb php@stefan-marr.de:
[...]

Thank you for your attention and I'm looking forward to hear your comments
:)

What about abstract methods in traits? I think this could be handy to
enforce the user class implement a data getter.

trait Foo {
public function doSomething()
{
return str_replace("foo", "bar", $this->_getString());
}
abstract protected _getString();
}

class Consumer
{
use Foo;
protected function _getString()
{
return "foo";
}
}

What do you think?

cu, Lars

Thank you for your attention and I'm looking forward to hear your comments

And thank you for this very detailed proposal, I wish most other feature
proposals were like this. I like the concept, it seems to solve some
of the problems we had to hack around now as well. I've two quick
questions for you:

1. can traits be put in a file of their own (I assume so actually)
2. can traits be autoloaded?

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

Hi,

generally asking, how would Reflection act on traits? Can this be
detected or will the information be lost after a class has been
assembled? E.g. detect if a certain method comes from a trait and which one?

lG

Hi,

I've updated the RFC on several sections to reflect the discussion on this list.

The following parts have been changed or added:

• introduced explicit description of abstract methods to be used as
  requirements
  specification for traits (useful to access state)
• moved part about interface propagation to the section of rejected features
• added a section about common misconceptions i.e. aliasing is not renaming
• added various syntax proposals

The important parts are included below. The new version of the RFC is available
at http://www.stefan-marr.de/rfc-traits-for-php.txt
and http://www.stefan-marr.de/artikel/rfc-traits-for-php.html

Some people proposed to implement only a subset of the proposed features,
especially !renaming! and abstract methods and visibility changes has
been mentioned to postpone on
a later version. I disagree on some of them.
At first, there is no renaming :) Hope, we could get this clear in the
next few days.
May be I should change the way of explaining it, but I've added the part about
misconceptions in the first place.
Second, abstract methods is a really common concept, the have the same
semantics like
for classes. So I expect them to be used the same way.
Third, the changes of visibility. Ok, they are nice but not essentially.
Would be ok to leave them out for now.

The next step could be to try to agree on one of the proposed notations?

Kind Regards
Stefan

Express Requirements by Abstract Methods
""""""""""""""""""""""""""""""""""""""""

Since Traits do not contain any state/properties, there is a need to describe
the requirements a Trait will rely on. In PHP it would be possible to utilize
the dynamic language features, but it is a common practice to give this
requirements explicitly.
This is possible with abstract methods like it is used for abstract classes.
::

<?php
trait Hello {
public function sayHelloWorld() {
echo 'Hello'.$this->getWorld();
}
abstract public function getWorld();
}

class MyHelloWorld {
private $world;
use Hello;
public function getWorld() {
return $this->world;
}
public function setWorld($val) {
$this->world = $val;
}
}
?>

The usage of abstract methods allows to state not always obvious relation ships
and requirements explicitly. It is favored over the implicit usage of the
dynamic method resolution and property creation in the context of complex
projects for the sake of readability.

Common Misconceptions

Aliasing vs. Renaming

The presented aliasing operation has not a semantic of renaming.
Instead it does only provide a new name to be able to invoke the original
method with this new name even if the original name was excluded.
::

<?php
trait A {
public function a() {
echo 'a';
$this->b();
}
public function b() {
echo 'b';
}
}

class Foo {
use A {
c => b
}
}

$foo = new Foo();
$foo->a(); //echos ab
$foo->b(); //echos b
$foo->c(); //echos b
?>

Since it is not renaming the original method b is still available and has not
been influenced at all.

Alternative Keywords for use
""""""""""""""""""""""""""""

The keyword use is already reserved for the new namespace feature.
Thus, alternative keywords already proposed on the mailing list are listed
here::

[1] exhibit
class Foo {
exhibit Bar;
}

[2] possess
class Foo {
possess Bar;
}

Alternative Expression of Exclusion
"""""""""""""""""""""""""""""""""""

Some people do not like the notation with the exclamation mark.
Possible alternatives::

[1] not keyword
use Trait {
not foo1, foo2;
bar => foo1
}

[2] without keyword
use Trait {
without foo1, foo2;
bar => foo1
}

Alternatives for the Aliasing Notation
""""""""""""""""""""""""""""""""""""""

Aliasing is often misunderstood as renaming.
May be some of the following notations will help::

[1] is keyword instead of the arrow
use Trait {
bar is foo1; //methodAlias is method
}

Interpretation: is state something about bar, there is nothing stated
about foo1.

Alternative keyword::

[2] from
use Trait {
bar from foo1; //methodAlias from method
}

Or an very explicit variation::

[3] from
use Trait {
alias bar as foo1;
}

Hi Stefan,

Thanks for writing such a good proposal.
In general I think traits is a very interesting idea. I can think of a few cases in my life as a programmer where it could have helped me out.

I think some comments re: the syntax/naming are good ones but I prefer not to get into naming in this email. I believe we can brainstorm re: naming when we figure out exactly what we want to do. I do support though finding a way which is simple for non-English speakers but not too simple like Perl:)

Thinking back at the times when something like this would have been useful to me I think there are a couple of main points I'd like to brainstorm about:

a)
I think Traits should be able to act as a self-contained behavior which can always be expected to work. For example if I want a Counter behavior I would like that not to depend on the properties in the containing class. While I don't think we should enable public nor protected properties in Traits I think allowing for private properties in Traits would come in very handy. It also is no problem when it comes to mangling as we can use the Trait name.

class Trait {
private $counter = 0;
function getNextSerialNumber() {
return $this->counter++;
}
}

I strongly recommend not to support protected/public and not to even get into the discussion of dealing with conflicts of such properties. But I think private is very useful.

b)
I haven't thought this through completely but I think we may want to consider a different model from supporting "removing" and "aliasing" of functions. I think this can create a lot of complications especially in larger works and it'll be write-once code and hard for a newcomer to the code to really understand.

I think the main reason to support removing/aliasing of functions is in order to avoid conflicts with other Traits/Class methods. Maybe what we can do is to have only "aliasing" but what it would do is to create a public function with the new name and convert the old function into a private function.
Benefits:

• Keeps the old code from running predictably without breaking dependencies.
• Possibly even allowing some form of "is-a" relationship to continue to be valid (and therefore the interface discussion may even be resolved; at least to a certain level). In the case I faced an is-a relationship (i.e. working instanceof operator) would have been nice.

I need to put a bit more thought into this but it's an initial attempt to provide an additional point of view which may actually give some more structure to the proposal while still delivering the benefits of this idea.

I think if this kind of idea could be fully baked it would solve the problems I have had in the past possibly without the more dangerous renaming/removing of functions. I have not looked into feasibility of this idea yet.

Anyway, good ideas and thanks for the very professional way you have brought this idea to the community.

Let's try and nail down the behavior and then we can have the harder naming discussion :) Just saying harder because I've always considered naming the hardest part in software engineering...

Andi

php@stefan-marr.de wrote:

Hi,

during last six months I've studied a language construct called Traits.
It is a construct to allow fine-grained code reuse and in my opinon
this would be a nice feature for PHP, which I did like to propose here.
The following RFC deals with the questions what Traits are, how they are
used, why they are usefull and how they do look like in PHP.
A patch implementing this new language construct is available, too.

Thank you for your attention and I'm looking forward to hear your comments
:)

Kind Regards
Stefan

I came across one piece of information on aliasing that may not be
obvious at first and therefore should probably be explicitly stated in
the RFC and in the manual when this makes it into the core.

Quoting http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf:
"Note that because the body of the aliased method is not changed in any
way, so an alias to a recursive method is not recursive."

This means that because there is no renaming of anything in the method
body when aliased, a recursive call to the method in the trait does not
make a recursive call in the aliased method. It will instead call the
original method name, which could be the same body, a method defined in
a different trait, or the method overridden by the client class.

--
"Joshua Thompson" spam.goes.in.here@gmail.com
<http://www.schmalls.com