The Trunk: Traits-ar.283.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Traits-ar.283.mcz

commits-2
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!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Traits-ar.283.mcz

Balázs Kósi
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

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Traits-ar.283.mcz

Igor Stasenko
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?
>
plusone.
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.