Hello Andi, I mentioned something along those lines as well. And I guess we both come from the side that a) we think the feature as such is useful and b) needs to be implemented in a way that we can use as much of the engine infrastructure as possible and c) not interfere with the way PHP works. That said we should not support hiding or dropping/removing of methods but simply making them private. Also we should make properties by default static to the the Trait, maybe disallowing implicit properties, so that we know the trait methods do bind the properties corredctly. Then for aliasing we can support public or protected aliases or just allowing to expose trait methods with a different visibility. This should not cause trouble as we can enforce conflict resolution. With such a feature set we are imo very flexible.
marcus Thursday, February 21, 2008, 7:09:27 PM, you wrote: > 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 Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
