Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35652
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.200.169 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=qmddwRrgV5agylxX6xWxX49/ko4Xa2GgIBIR1ed5UBfgWS9HI9jEAsVpRLJk/Gjw5JGr9+RCsem/7fHEqZTGR3Zo3sgg5o78/pLdyldC/Oslnkjdgz3F4xD5EUZ/48TFSFVnUEbeA1kWzoRsDbSXvnNGb2QZ/5WW4COBezW9+a0=
Message-ID: <1e12984d0802201000s22a16ee0u6825018443171498@mail.gmail.com>
Date: Wed, 20 Feb 2008 19:00:52 +0100
Reply-To: php@stefan-marr.de
Sender: stefan.marr.de@gmail.com
To: internals@lists.php.net
Cc: "=?ISO-8859-1?Q?Marcus_B=F6rger?=" <helly@php.net>, 
	"=?ISO-8859-1?Q?Johannes_Schl=FCter?=" <johannes@php.net>, 
	"Sebastian Bergmann" <sb@sebastian-bergmann.de>, 
	"Alexandre Bergel" <alexandre@bergel.eu>, 
	"Falko Menge" <falko.menge@hpi.uni-potsdam.de>, 
	"Sara Golemon" <pollita@php.net>, derick@php.net
In-Reply-To: <001c01c87264$3c01b4e0$b4051ea0$@de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <001c01c87264$3c01b4e0$b4051ea0$@de>
Subject: Re: RFC: Traits for PHP
From: php@stefan-marr.de ("Stefan Marr")

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;
}