Yes, I guess it does. That's easily solvable by adding a
Monticello-Traits package. But this way Traits is at least a bit
cleaner. I'll give the North Americans time to respond, but as long as
these methods stay out of Traits, I'm happy.

frank

On 7 August 2013 21:01, Tobias Pape <Das.Linux at gmx.de> wrote:
> This one is dangerous.
>
> It makes monticello directly depend on traits,
> and unloading traits wont work no longer, no?
>
> Best
>     -Tobias
>
> Am 07.08.2013 um 21:56 schrieb commits at source.squeak.org:
>
>> Frank Shearar uploaded a new version of Traits to project The Trunk:
>> http://source.squeak.org/trunk/Traits-fbs.297.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Traits-fbs.297
>> Author: fbs
>> Time: 7 August 2013, 6:52:54.132 pm
>> UUID: 00f10a78-c0a1-a243-a90d-d0a642804ab8
>> Ancestors: Traits-fbs.296
>>
>> #asClassDefinition, #classDefinitions implementors belong in Monticello.
>>
>> =============== Diff against Traits-fbs.296 ===============
>>
>> Item was removed:
>> - ----- Method: Trait>>asClassDefinition (in category 'monticello') -----
>> - asClassDefinition
>> -    ^Smalltalk at: #MCTraitDefinition ifPresent:[:aClass|
>> -        aClass
>> -            name: self name
>> -            traitComposition: self traitCompositionString
>> -            category: self category
>> -            comment: self organization classComment asString
>> -            commentStamp: self organization commentStamp].!
>>
>> Item was removed:
>> - ----- Method: Trait>>classDefinitions (in category 'monticello') -----
>> - classDefinitions
>> -    | definitions |
>> -    definitions := OrderedCollection with: self asClassDefinition.
>> -    (self hasClassTrait
>> -        and: [self classTrait hasTraitComposition
>> -        and: [self classTrait traitComposition isEmpty not]])
>> -            ifTrue: [definitions add: self classTrait asMCDefinition].
>> -    ^definitions asArray!
>>
>>
>