Andreas Raab uploaded a new version of Traits to project The Trunk:
http://source.squeak.org/trunk/Traits-ar.283.mcz ==================== Summary ==================== Name: Traits-ar.283 Author: ar Time: 11 March 2010, 8:51:35.08 am UUID: 68a46760-cb16-874a-a84d-2ac3da946f79 Ancestors: Traits-ar.282 Fix SystemChangeNotification for traits. NB, SystemNotification is broken: It requires passing in *both* old and new class/trait verbatim even though they cannot both exist at the same time and even though copying is not desirable (for the current trait implementation copying would mean recompiling all methods). So we pass in a shallowCopy to avoid excessive recompilation but of course if a client ever looks deeply inside it it will quickly find that it's not a copy. This should be fixed by passing a description of some sort (similar to MCClassDefinition) or specifically the values that were changed. =============== Diff against Traits-ar.282 =============== Item was changed: ----- Method: ClassTrait>>uses: (in category 'initialize') ----- uses: aTraitComposition + | newTraits copyOfOldTrait | + copyOfOldTrait := self shallowCopy. - | newTraits | newTraits := aTraitComposition asTraitComposition. newTraits traitsDo:[:t| (t isBaseTrait and:[t classSide hasMethods]) ifTrue:[self error: 'Cannot add: ', t]. (t isClassTrait and:[(baseTrait includesTrait: t baseTrait) not]) ifTrue:[self error: 'Cannot add: ', t]. ]. + self installTraitsFrom: newTraits. + SystemChangeNotifier uniqueInstance + traitDefinitionChangedFrom: copyOfOldTrait to: self.! - self installTraitsFrom: newTraits.! Item was changed: ----- Method: Trait classSide>>named:uses:category:env: (in category 'instance creation') ----- named: aSymbol uses: aTraitComposition category: aString env: anEnvironment + | trait oldTrait systemCategory | - | trait oldTrait systemCategory oldCategory | systemCategory := aString asSymbol. + trait := anEnvironment at: aSymbol ifAbsent: [nil]. + (trait == nil or:[trait isMemberOf: Trait]) ifFalse: [ - oldTrait := anEnvironment at: aSymbol ifAbsent: [nil]. - oldTrait ifNil:[ - trait := Trait new. - ] ifNotNil:[ - oldCategory := oldTrait category. - trait := oldTrait. - ]. - (trait isMemberOf: Trait) ifFalse: [ ^self error: trait name , ' is not a Trait']. + + oldTrait := trait shallowCopy. + trait ifNil:[trait := Trait new]. + trait setName: aSymbol andRegisterInCategory: systemCategory environment: anEnvironment. trait uses: aTraitComposition. "... notify interested clients ..." oldTrait ifNil:[ SystemChangeNotifier uniqueInstance classAdded: trait inCategory: systemCategory. ] ifNotNil:[ + SystemChangeNotifier uniqueInstance traitDefinitionChangedFrom: oldTrait to: trait. + systemCategory = oldTrait category ifFalse:[ - systemCategory = oldCategory ifFalse:[ SystemChangeNotifier uniqueInstance class: trait recategorizedFrom: oldTrait category to: systemCategory]. ]. ^ trait! |
Hi,
I just wanted to ask: Should we store the actual items that have changed or some sort of description like MCDefinition or DSChange?. > This should be fixed by passing a description of some sort (similar to MCClassDefinition) or specifically the values that were changed. The next question is: could we reuse one of these? I think, actually DSChange [1] models exactly what we want. So what about announcing DSChange (and DSDoIt) objects, and providing a compatibility protocol with AbstractEvent. If this would work out, it would simplify SystemChangeAnnouncer implementation greatly, and pave the way for DeltaStream adoption. What do you think? Balázs [1] You can take a look what DSChanges are by evaluating: Installer ss project: 'DeltaStreams'; package: 'DeltaStreams-Model'; browse |
On 12 March 2010 15:43, Balázs Kósi <[hidden email]> wrote:
> Hi, > > I just wanted to ask: > Should we store the actual items that have changed or some sort of > description like MCDefinition or DSChange?. > >> This should be fixed by passing a description of some sort (similar to MCClassDefinition) or specifically the values that were changed. > > The next question is: could we reuse one of these? > I think, actually DSChange [1] models exactly what we want. > So what about announcing DSChange (and DSDoIt) objects, > and providing a compatibility protocol with AbstractEvent. > If this would work out, it would simplify SystemChangeAnnouncer > implementation greatly, and pave the way for DeltaStream adoption. > What do you think? > I think that if you could change it to make it simplier and DS-compatible, then do it :) > Balázs > > [1] You can take a look what DSChanges are by evaluating: > > Installer ss > project: 'DeltaStreams'; > package: 'DeltaStreams-Model'; > browse > > -- Best regards, Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |