WAUserConfiguration #rootClass - direct class access?

[dalehenrich]

Given a WAUserConfigration for a WAApplication:

(class)@              -> WAUserConfiguration
(oop)@                -> 251026433
(committed)@          -> true
cachedSearchContexts@ -> anIdentityDictionary( )
expressions@          -> aDictionary( #'rootClass'->aWAValueExpression)
parents@              -> anOrderedCollection( aWARenderLoopConfiguration, aWASharedConfiguration)

the #rootClass expression references a WAValueExpression:

(class)@     -> Dictionary
(oop)@       -> 269276673
(committed)@ -> true
1@           -> #'rootClass'->aWAValueExpression

which in turn directly references a class:

(class)@     -> WAValueExpression
(oop)@       -> 269021697
(committed)@ -> true
key@         -> #'rootClass'
value@       -> WACounter

In GemStone, changing the WACounter class will cause a new class version to be created, while the #rootClass expression will return the original class version ....

[dalehenrich]

There seem to be a view places where the value of the WAValueExpression is a SymbolAssociation that is identical to the result of Smalltalk associationAt: which seems consistent with a WAClassBindingAttribute, but not necessarily the same ...

[dalehenrich]

I realized that I needed to include a bit more context for the location of the WAConfiguration instance in the initial bug comment ... it is from the configuration slot of the counter WAApplication:

..             -> 'counter'->aWAApplication
(class)@       -> WAApplication
(oop)@         -> 250405377
(committed)@   -> true
cache@         -> aWABulkReapingCache
configuration@ -> aWAUserConfiguration
filter@        -> aWAValueHolder contents: aWAExceptionFilter
parent@        -> aWADispatcher

[dalehenrich]

related to the fix for Issue #820

[jbrichau]

Seems like the gemstone branch version of the Seaside-Tools package was still being loaded by the baseline. That, at least, explains the issue with #rootClass.

[jbrichau]

My comment above was probably not related to your observation, though I remember that there was an issue at that time when loading the code did not load the correct packages and hence did not include the necessary changes.

More to the point: the SymbolAssociation is indeed the result of Smalltalk associationAt: and, through experiments, always holds on to the latest class version. It does rely on GRPlatform>>bindingOf: to return that association.

I consider this issue closed but if I did not completely grasp the concern, please reopen it!

[dalehenrich]

No problemo. if the association is the one from the symbol dictionary then we're good to go ..