See below: > -----Original Message----- > From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 21, 2008 12:41 AM > To: Andi Gutmans > Cc: [EMAIL PROTECTED]; internals@lists.php.net; Marcus Börger; > Johannes Schlüter; Sebastian Bergmann; Alexandre Bergel; Falko Menge; > Sara Golemon; [EMAIL PROTECTED] > Subject: Re: [PHP-DEV] RFC: Traits for PHP > > > On 21.02.2008, at 03:26, Andi Gutmans wrote: > > > 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. > > Of course this could be nice, but I think this is maybe the point > where one should move to delegate?
I don't think so. I think the value here is not copy&paste but to be able to encapsulate some functionality which a class can be decorated with. Giving a basic storage mechanism to that would be very beneficial in a large amount of uses. Again, I am proposing private storage only which would be for internal use-only by the decorating methods. > > 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 am probably not seeing the obvious here, but how does making the > function private solve the naming collisions? My concern about removing/aliasing functions is that you can really do some very funky stuff. It almost takes me back to the spaghetti code days where you can jump into code someplace in the middle. My proposal would make Traits a bit stricter and ensure that the original interface would still exist after it is aggregated. Either by honoring the interface and redefining methods which are consistent with the Trait or by leaving the original methods around as privates so that they can still reference each other. I think being able to remove a method which may need to be used by some internal method is a bit too chaotic. When you're inheriting large code bases it can become complicated to manage. I very much see the value of Traits but I think we should also consider making them a bit stricter. Btw, the "private property" discussion is different from the 2nd one. They are mutually exclusive. The latter idea would give more structure, still enforce a contract but should provide the same value. I am not convinced it's feasible on an implementation side but I think we should first consider it from a functional point of view. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
