Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51014
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 85.88.12.247 cause and error)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <AANLkTimUdjA6pAVMN1V7Nr2En46AO_82iit1XfAXgtVY@mail.gmail.com>
Date: Sun, 12 Dec 2010 11:59:38 +0100
Cc: "internals@lists.php.net Development" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <665EF237-6DCF-4CB1-ACA7-6F2C193512F1@stefan-marr.de>
References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de> <AANLkTimUdjA6pAVMN1V7Nr2En46AO_82iit1XfAXgtVY@mail.gmail.com>
To: Nathan Nobbe <quickshiftin@gmail.com>
Subject: Re: [PHP-DEV] Traits and Properties
From: php@stefan-marr.de (Stefan Marr)

Hi Nathan:

On 11 Dec 2010, at 19:35, Nathan Nobbe wrote:

> Regarding visibility modifiers, why not carry them over from the trait =
directly, private in the trait definition results in private in the =
class definition.

The problem will be hopefully more clear in the following example:

trait StateMachineDoor {
  private $currentState;
  public function open() {....}
}

trait StateMachineElevator {
  public $currentState;
  public function callElevator() { ... }
}

These two traits are not compatible since currentState has different =
semantics in both traits.
With the current design of traits, there is no language solution to this =
problem.

The suggestions to avoid the problem are to use better names like =
$currentDoorState and $currentElevatorState, or to rely on accessors =
which is currently the only variant in which the programmer will notice =
that there is an incompatibility:

trait StateMachineDoor {
  abstract function &getCurrentState();
  public function open() {....}
}

trait StateMachineElevator {
  abstract function &getCurrentState();
  public function callElevator() { ... }
}

However, you might have a different situation, one where the traits are =
composable with respect to their state, i.e., they need to work on the =
same state:

trait OutputIterator {
  public $array;  // not sure why that is public here, but the =
implementor chose to make it public...
  public function printNext() {...}
}=20

trait SortArray {
  private $array; // this developer chose to make the array private, for =
what ever reason...
  public function doSort() { ... }
}

I hope that makes the possible situations clear: state can either be =
composable or not, that really depends
on the trait. And there is no language solution for it build in at the =
moment.

So, back to my original question:

class SomethingOutputableAndSortable {
  use OutoutIterator, SortArray;
}

What is the visibility of $array supposed to be in this class? private =
or public?

And further, in the very first example of this mail, ideally there =
should be some warning, however, that warning would be annoying for the =
last example, since here the state does not collide...

Best regards
Stefan

PS: there has been discussion on stateful traits before, but the =
language solutions to that where considered to complex.

--=20
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525