Andreas Raab wrote:
> Daniel Vainsencher wrote:
> 
>> Well, while Class and friends may be an exception, I would generally 
>> shy from creating a class with 15 responsibilities. Too much 
>> responsibility leads to madness. Maybe it needs to learn to delegate 
>> and cooperate more :-)
> I actually agree - but you know if you take that approach seriously you 
> shouldn't use traits at all ;-) Simply because you have given people a 
> tool for dealing with more complexity per object and they will use it.
Funny you should mention that. I'd guess package extensions are the more 
dangerous in that perspective.

We were talking a couple of weeks ago here in Portland that it doesn't 
seem that bad to add responsibilities to a parser using method 
extensions instead of a visitor pattern.

I think Traits will just allow people to combine stuff to whatever 
complexity they need anyway using less baroque glue than they do now.

>>> For TAccessingMethodDictDescription (which I am choosing only because 
>>> it's the first in the category and not too long) we have the following 
>>  >   #compiledMethodAt:ifAbsent:
>>  >     -> TMethodDictionaryBehavior
>> This is a natural requirement
> But making precisely my point. Why separate "accessing a method 
> dictionary" from the "being a method dictionary"? Can you ever "access a 
> method dictionary that is not a method dictionary"? It just feels as if 
> we're putting needless complexities on top of each other.
Well, if I gather correctly, this is a case of behavior that is 
implemented in Behavior and then overridden in CD to account for method 
categories (see implementors of #removeSelector: for example). So maybe 
TAMDD (along with TBasicCat...) should be called 
TManagingCategorizedMethods.


[about usage of #noteAddedSelector:meta:]
> I agree with your analysis - it's actually a nice example for how you'd 
> (re-)design this with traits.
Well, actually, looking a bit closer, it now appears to me that this 
whole responsibility needs to be shed and made a client of 
SystemChangeNotifications... but that's besides the point.

>> I think "people trying to understand the system" is too wide. People 
>> trying to understand behavior should probably not concern themselves 
>> with traits at all. Just look at the resulting flat class. For people 
>> trying to understand the dependencies (maybe they want to reuse), the 
>> complex dependencies were already there before the traits. The method 
>> categories we about as fine grained, except they did help because they 
>> have no semantics and no tool support (requires).
> But here I disagree. I think you will *want* to show people the traits 
> in a sensible way when they explore a class - if only to make it easier 
> to see what responsibilities are involved, what the class uses verbatim 
> and where it differs (extremely important as this is where the 
> "integration" happens and as we all know integration is one of the 
> hardest things to do well and to understand).
So do you have a proposal for new features that would help beyond those 
in the Prototype image? that shows the requires, overrides, and 
provides, in addition to showing the Composition structure more or less 
as we show it in the StructureBrowser you've seen already.

>> Actually, trying to track down the information I needed for the 
>> analysis above, I feel exactly what you mean. To support understanding 
>> the link, we really need tool support to tell us "what methods are 
>> requiring this", and "who is providing method in this context".
> A simple yet important thing to do would be to hide the "implementors" 
> if they use ("inherit") the method from a trait verbatim. This is 
> equivalent to not showing subclasses which albeit responding to a 
> message do not implement it "locally".
This sounds to me like the -own- category in the Prototype image. Or do 
you mean something beyond that? I think not showing non-local methods at 
all is problematic, because it forces one to always look for extra 
methods in the (now multiple) places they could be got from. This was 
not as bad with inheritance, because one could chase a single chain... 
though this makes me think it might be useful to make the browser by 
default a sort of protocol browser, allowing dynamically controlled 
filtering of what gets shown - both from Traits, and from inheritance.

>> I disagree with that - code duplication causes the creation of 
>> inconsistent variations, and that causes bug-fix hell, and destroys 
>> coherence.
> That really depends. Code duplication does all that but it also 
> decouples subsystems (good) and makes sure one has control over critical 
> portions of code (good) and then some ;-) It all depends on how much and 
> where and why code is being duplicated. In general, I agree that within 
> a (sub-) system under your control code duplication is a bad idea but 
> if, for example, a critical algorithm depends on the (current) rounding 
> behavior of line segment intersection it may be very well worthwhile to 
> duplicate it since somebody might go and change that rounding behavior 
> without you knowing it.

That is a pretty impressive case for cases in which duplicated code 
might be worth the costs. I'm not sure I buy it (maybe if the critical 
algorithm depends on the current rounding behavior, that behavior should 
be named and made part of the spec), but I'll keep it in mind.

> The reason why I am mentioning this is that with traits you can have 
> many of these "remote effects" since it may not obvious to you which 
> other users of that trait there are. 
Of course this is a tools issue, and at least as far as users in the 
image are concerned, it is easily solved.

Daniel Vainsencher