On Fri, Dec 10, 2010 at 1:00 PM, Nathan Nobbe <quickshif...@gmail.com> wrote: >> >> As a note, I'm not strongly opposed to this proposal, since I don't >> think it would do any harm. It just seems to me like a "kitchen sink" >> feature. >> >> The issue for me is that traits, as I understand them, are there >> primarily for horizontal code re-use via compile-time "copy/paste". >> With that in mind, I feel like the developer is responsible for making >> sure the methods they copy into their classes make sense, just as they >> would have to do if they physically copied and pasted them. > > Copy & paste itself leads to duplicated unmaintainable code, so traits are > introduced (among other reasons) to prohibit this practice. Why not take it > a step further and let a trait definition be as expressive as possible, > eliminating ambiguity, right out of the gate? > >> >> I think your example above isn't quite what you meant to show, since >> you're requiring a specific class and not an interface (since PHP only >> allows one class definition for a class name, you're not gaining >> anything via traits, since the trait could only be used for that >> specific class, in which case why not just have the code in the class >> in the first place?). > > In retrospect Chad, that's a good point, and perhaps there is no reason to > allow marking of classes as required by traits. > >> >> If we take your example in a more general case using interfaces, I >> still can't see what the benefit is. All it does is provide a more >> explicit and immediate error message for developers (e.g. instead of >> "method not found" error when the bad method call is made at runtime, >> you get a "classes using trait <trait> must implement <interface>" at >> compile time). > > Exactly, catch it at compile time rather than runtime, that's all it is > really, just like the benefit of discovering a given subclass doesn't > implement a given abstract method so that I don't go any further and run > code guaranteed not to work. > >> >> Again, I'm not against it, but maybe be too much hand holding, since >> the developer should make sure using the trait makes sense first? > > Couldn't the same be said for a developer extending an abstract class, or > implementing an interface? And also, a developer is to look through the > entire definition of a trait to know which methods it's going to depend on? > I know abstract is there as Stefan showed, but as we've both observed that > approach can get messy quickly. > -nathan >
I think that you make a convincing argument. Thinking more about your Iterator example, this idea makes a lot of sense and could be quite useful. Also, I was wrong about requiring a class. It could be very useful, especially if it is an internal class (e.g. ArrayObject) which might have many children, and of course in this case the parent can't be changed. I think the require keyword works well. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
