Hello, PHP developers, I'm new to the list, but have been using PHP for a number of years, have done a little hacking in the source code, and have an interest in the development of the language.
Particularly recently I have been reading with a good deal of excitement Stefan Marr's RFC on 'horizontal reuse' on the PHP Wiki: http://wiki.php.net/rfc/horizontalreuse The trait functionality looks like a great start and an innovative language development, and I'm looking forward to trying it out soon (when I can find some more time!), and particularly looking forward to making good use of it when it makes it into a release. While it's still in the pre-release stage, though, I would like to put in a vote for the assignment syntax: I think it is a lot easier to read and understand than the 'insteadof' syntax. I would also like to propose some extensions to the functionality as currently described, which I think could potentially add tremendous power to the mechanism, with relatively little additional conceptual complexity and implementation effort. I've written it up as a bit of a proposal below. I'd love to hear what you think. I would be willing to play a part implementing it, too. Cheers, Ben. ============================= Proposed extensions to traits ============================= Background ========== Traits in PHP [1] enable improved code reuse. They can be simplistically viewed as compiler-assisted copy-and-paste. Methods designed to be reused can be defined in traits and then these traits can be used in classes. The traits are 'flattened', so it is as if the trait methods were defined directly in the class in which they are used. Traits can access other methods and properties of the class, including those of other traits. They also fit in with the method overriding system: methods defined directly in a class override those in used traits, which in turn override those in ancestor classes. There are two limitations of traits in their current implementation for which I would like to propose extensions. The first limitation is that traits can very easily break, particularly when methods are omitted from classes in which the rest of the trait is used, or shadowed by method definitions in the class proper. The second limitation is that the trait overriding semantics are impoverished and needlessly restrictive. Breakability ============ Limitation ---------- There are two main aspects of traits which make them easy to break: incorrect method calls and unintentionally shared state. Incorrect method calls spring from the way trait methods can be omitted from classes where the rest of the trait is used, or shadowed by methods defined in the class proper. In either of these scenarios, any call in a trait to such a method may not call the method that was originally intended--they may fail, or they may call a different method, with unpredictable results. Of course, sometimes such a behaviour is desirable, if writing a trait which communicates with the rest of the class by means of method calls, yet provides a fallback methods in case the class author does not wish to provide such methods. However, when it is not intended, this could lead to incorrect and difficult-to-pinpoint behaviour. The other way traits can break is by unintentionally sharing state. Traits may make use of the same data members (not recommended, but possible), or the same accessors, when each should actually have their own independent state. Again, this could lead to incorrect and difficult-to-pinpoint behaviour. Example ------- trait ErrorReporting { public function error($message) { $this->print($message); } private function print($message) { fputs($this->output,$message."\n"); } } class Printer { use ErrorReporting; public $output=null; public function print($document) { /* Send the document to the printer--$this->output. */ /* ... */ if (there_was_an_error()) { $this->error("printing failed"); } /* ... */ } } This example is very contrived, and hopefully no programmer would be silly enough to fall into this exact trap. However, it is easy to imagine more subtle cases where this kind of thing could happen, particularly as traits and classes are modified from their original conception. The ErrorReporting trait allows the programmer to report errors in a consistent way by using the trait in many classes. It includes a print() method that is used to print the error to the screen. However, this method has been unintentionally shadowed by a print method in the class, intended to print a document on a printer. No error or warning will be generated, but the class will not work as intended; probably it will infinitely recurse; a nasty problem to track down. Furthermore, even if the incorrect method call didn't occur, there would be data-sharing problems, as both the ErrorReporting trait and the class' print() function make use of the $output data member, unintentially sharing data. Proposal -------- I suggest these problems should be solved from two angles. Firstly, additional warnings should be triggered to alert the programmer to the problems, and secondly, the traits mechanism should be extended to allow more desirable behaviours to be programmed. Warnings - - - - To avoid silent unintended shadowing, I suggest issuing a warning when a conflict between trait and class methods occurs. So this would trigger a warning: trait SaySomething { public function sayIt() { echo "Something\n"; } } class Sayer { use SaySomething; public function sayIt() { echo "Hello world!\n"; } } Something such as this would be required to suppress it: use SaySomething { sayIt = null; } or perhaps with a more 'insteadof'-like syntax something like: use SaySomething { unset sayIt; } This indicates that no sayIt() method should be included from any trait (and thus there is no conflict with any sayIt() method defined in Sayer). We could also have: use SaySomething { sayIt = SaySomething::sayIt; } which would also suppress the warning, but indicates that we know what we are doing--we desire the trait method to be included. This is only useful in combination with my proposal for dealing with overriding below ('prev'). Extension - - - - - I suggest these two problems can be simply solved by introducing two additional uses of the trait keyword: as a scoping keyword and an access specifier. As a scoping keyword, it would be used analogously to self. Method calls such as $this->print() could be replaced with trait::print() when the programmer desires to ensure that their trait method, and only their trait method, is called--when there is no intention that overriding should be possible. It would only be able to be used in a trait, and could only be used to reference methods or properties defined in the same trait, using their original name. As an access specifier, it would be used instead of public, private, etc. in trait definitions, to mean that the member (data or method) can and can only be accessed using the mechanism above (trait::). Implementation could be very simple. When flattening a trait into a class, every trait method, and every trait property with trait level access, could be included with a mangled name (e.g. making use of the reserved __ prefix and/or characters which are illegal in code, e.g. __trait-TraitName-methodName), and any occurrences of trait:: scoping in any trait method body could be replaced with a call to the same kind of mangled name (e.g. trait::print() becomes $this->__trait-ErrorReporting-print()). Data members could be treated in exactly the same way (e.g. trait::$output becomes $this->__trait-ErrorReporting-output). Static members pose no additional problems. When flattening a trait into another trait, the mangling/transformation is slightly different, but not much harder. Perhaps a little demangling code for backtraces and/or error messages would be nice. This would be sufficient, though. The trait access specifier is nothing more than an indication that a method should be omitted with its unmangled name (essentially the same as an insteadof directive, but without any method taking its place), or that a property should be included with a mangled name, rather than going through the existing property conflict checking mechanism. I realise a proposal for non-breakable traits [2] has already been declined. However, I believe my proposal here is simpler to understand and implement. It doesn't introduce any new overriding or property-sharing semantics, doesn't overload the public and private keywords with confusing additional meanings, and fits better with PHP's dynamic nature by not requiring a decision at compile time about whether or not to mangle a name (most notably in method bodies). Rewritten example ----------------- The original example would work as desired if rewritten thus: trait ErrorReporting { trait $output = STDOUT; public function setErrorOutput($output) { trait::$output = $output; } public function error($message) { trait::print($message); } trait function print($message) { fputs(trait::$output,$message."\n"); } } class Printer { use ErrorReporting; public $output=null; public function print($document) { /* Send the document to the printer--$this->output. */ /* ... */ if (there_was_an_error()) { $this->error("printing failed"); } /* ... */ } } Overriding ========== Limitation ---------- At present, the overriding semantics of traits are that a method defined in a class proper overrides a method defined in a used trait which in turn overrides a method defined in an ancestor class. However, to my knowledge, there is no way for a class method to call a trait method by the same name. Furthermore, it is my belief that completely disallowing trait methods of the same name, rather than allowing an overriding behaviour between traits, is needlessly restrictive. Proposal -------- I would therefore like to propose an extension backwards-compatible with the current trait implementation. I will, however, extend the assignment syntax, rather than the 'insteadof' syntax, as I find that clearer, and more amenable to this extension. Of course, though, other syntaxes could be found. There are four aspects to this extension: (1) Introducing a new scoping keyword. (2) Allowing a method name to be used from multiple traits. (3) Allowing a trait to be included multiple times. (1) Introducing a new scoping keyword. - - - - - - - - - - - - - - - - - - - I suggest something such as 'prev', to refer to the previous definition of the method. Similar to 'parent', and the same in the absence of traits, this refers to the 'next higher definition in the trait hierarchy'; the 'trait hierarchy' is pictured like the 'class hierarchy' but including traits. So if 'prev' is used in a class method when a trait method of the same name exists, it will refer to the trait method, rather than referring to a method in a parent class. Alternatively, the 'parent' keyword meaning could be changed to have this meaning. My apologies if this is already the case: I have not played with the implementation in the trunk (though look forward to doing so at some stage) so am basing my comments purely on the RFC. (2) Allowing a method name to be used from multiple traits. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - When multiple methods of the same name are defined they simply take their place in the 'trait hierarchy' and can be accessed by means of 'prev' (see (1) above). So we could write, for instance: trait Hello { public function sayIt() { echo "Hello "; } } trait World { public function sayIt() { prev::sayIt(); echo "world "; } } class HelloWorld { use Hello, World { sayIt = Hello::sayIt, World::sayIt; } public function sayIt() { prev::sayIt(); echo "!\n"; } } $o = new HelloWorld(); $o->sayIt(); // Outputs "Hello world !\n" sayIt() in the class overrides sayIt() in World, which overrides sayIt() in Hello, but all are included. The first two make use of 'prev' to reference those higher up the hierarchy. (3) Allowing a trait to be included multiple times. - - - - - - - - - - - - - - - - - - - - - - - - - - This is only useful with the extension I proposed above to deal with breakability, where traits can be somewhat isolated. However, the trait is simply given multiple names by which to refer to it when it is used, and then its methods are referenced using those names. So, for instance: trait PublicQueue { trait $arr = array(); public function add($item) { trait::$arr[]=$item; } protected function remove() { return array_shift(trait::$arr); } } class OperationManager { use Q1=PublicQueue, Q2=PublicQueue { localQueue = Q1::add; remoteQueue = Q2::add; localUnqueue = Q1::remove; remoteUnqueue = Q2::remove; add = null; remove = null; } public function process() { while ($i=$this->localUnqueue()) echo "local $i\n"; while ($i=$this->remoteUnqueue()) echo "remote $i\n"; } } $o = new OperationManager(); $o->localQueue("one"); $o->remoteQueue("two"); $o->localQueue("three"); $o->process(); // Outputs local one\nlocal three\nremote two\n Implementation - - - - - - - I don't think any of this poses particular implementation difficulties. Everything that is necessary is pretty obvious: name mangling of trait methods needs to use the aliases (e.g. Q1 in the example) rather than the original trait name; multiple methods need to be able to be included in a single class, with an ordering; and 'prev' needs to start a method search at the current class, but not actually make a call until the method using 'prev' has been passed in the search (or else, have some way of starting the method search at the relevant place within a class); only when prev is used is anything but the first method with a given name called. Fuller example ============== A more 'real-world' example is definitely in order now. One possible scenario where all this kind of functionality could be useful is in defining active record classes, where objects can 'retrieve themselves' from a database, and 'update themselves' in the database. There are many different semantics for records which could be added incrementally with overriding traits, to construct classes with many different behaviours and combinations of behaviours. With many, many database record types, a lot of code reuse could be avoided. Just a taste: abstract class ActiveRecord { protected $new; protected $id; protected $other_values; protected function __construct($id,$values,$new) { $this->id=$id; $this->other_values=$values; $this->new=$new; } public function save() { if ($this->new) { if (!create_in_the_database()) return false; if ($this->id===null) $this->id=last_insert_id(); } else { if (!update_in_the_database()) return false; } return true; } public static function new() { return new static(null,static::$default_values,true); } public static function get($id) { return new static($id,get_from_the_database(),false); } } trait LoggingOperations { public function save() { if ($this->new) { log("Creating ".get_called_class()); } else { log("Updating ".get_called_class()." ID ".$this->id); } if (!prev::save()) { log("Failed"); return false; } log("Succeeded"); return true; } } trait EnsuringNoConcurrentChanges { trait $original_values = array(); protected function setOriginalValues($values) { trait::$original_values = $values; } public static function get($id) { $record = prev::get($id); $record->setOriginalValues($record->other_values); return $record; } public function save() { $current_values=select_from_database(); if ($this->new&&$current_values) return false; if (!$this->new&&!$current_values) return false; if ($current_values!=trait::$original_values) return false; return prev::save(); } } trait UsingHashesForIDs { public function save() { if ($this->id===null) $this->id=random_hash(); return prev::save(); } } class SessionRecord extends ActiveRecord { protected static $default_values=array( 'user'=>'', 'time'=>'' ); use UsingHashesForIDs; } class Client extends ActiveRecord { protected static $default_values=array( 'user'=>'', 'name'=>'', 'address'=>'' ); use EnsuringNoConcurrentChanges, LoggingOperations { save = EnsuringNoConcurrentChanges::save, LoggingOperations::save; } } Obviously, other combinations are possible, too. Admittedly, with things this simple, a single base class with configurable options would probably be sufficient, but with additional complexity, traits that can override each other definitely offer a distinct advantage with a great amount of possible code reuse. There is a huge amount of power available here, I think, which is unlocked by these proposed extensions. Final note regarding grafts =========================== My proposals here are not a replacement for grafts [1]. Grafts can be viewed as compiler-assisted use of the delegate design pattern, and come with all the benefits of that pattern. As such, they allow greater isolation than traits and greater ability to use helper classes by passing themselves via $this to other methods (which can then rely on access to all the grafted class' public methods, without knowledge of the enclosing class or which of the grafted class' methods it forwards to). Regarding the problem of maintaining encapsulation when doing such things as returning $this from a graft method. I suggest perhaps the 'PHP way' of solving this would be to provide a get_called_object() method, so one can return get_called_object() rather than return $this. It could be problematic when grafts nest, but perhaps with some worked examples and experience, would be found to be sufficient. In my opinion, having $this behaving different ways in different contexts isn't just difficult, but really isn't feasible--the programmer's intentions can't be guessed adequately to make that kind of thing work. References ========== - [1] http://wiki.php.net/rfc/horizontalreuse - [2] http://wiki.php.net/rfc/nonbreakabletraits -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
