Smalltalk › Gemtalk › GLASS

order of classvars changed after load

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

GLASS mailing list

order of classvars changed after load

Hi,

I noticed a class getting a new class version when there had only been changes to class methods on a class.
After investigation, it’s because the order of class variables seemingly changed
from:
classVars: #( ObjectsForKeyword ObjectsForScope ObjectTestsForScope PropertiesForKeywords)
to:
classVars: #( ObjectTestsForScope ObjectsForKeyword ObjectsForScope PropertiesForKeywords)

However, the already loaded mcz file and the new mcz file for the package of this class have the same ordering (the last one) defined.
When I use Monticello to check for ‘changes’ in the image with respect to the current loaded mcz, it reports the changed class variable ordering.
However, merging the new mcz into the image does not detect these changes, only a ‘full load’ triggers the setting of a new class version.

Summarizing, it seems the class definition in the image has a different class variable ordering defined than what was/is in the mcz file.

Is there any ‘class var reordering’ logic going in during such loads? Not sure if I can reproduce this, because it’s a bit hard to find out when this class var order change would have occurred.

Johan

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Richard Sargent

Re: order of classvars changed after load

Administrator

GLASS mailing list wrote

Hi,

I noticed a class getting a new class version when there had only been changes to class methods on a class.
After investigation, it’s because the order of class variables seemingly changed

Since the class variables are held in a Dictionary, there really is no "order", per se. While the class creation method may require an Array argument, the order implied by the collection is not preserved.

If you look at the implementation of #'subclass:instVarNames:classVars:classInstVars:poolDictionaries:inDictionary:newVersionOf:description:options:', you will see that it tests for equivalency of the new definition to the existing one. There have been changes in recent times to this mechanism in order to reduce/eliminate the number of cases in which a new class version is created unnecessarily. I think this was in one of the 3.2 releases, but I don't recall which one.

What version of GemStone are you using?

from:
classVars: #( ObjectsForKeyword ObjectsForScope ObjectTestsForScope PropertiesForKeywords)
to:
classVars: #( ObjectTestsForScope ObjectsForKeyword ObjectsForScope PropertiesForKeywords)

However, the already loaded mcz file and the new mcz file for the package of this class have the same ordering (the last one) defined.
When I use Monticello to check for ‘changes’ in the image with respect to the current loaded mcz, it reports the changed class variable ordering.
However, merging the new mcz into the image does not detect these changes, only a ‘full load’ triggers the setting of a new class version.

Summarizing, it seems the class definition in the image has a different class variable ordering defined than what was/is in the mcz file.

Is there any ‘class var reordering’ logic going in during such loads? Not sure if I can reproduce this, because it’s a bit hard to find out when this class var order change would have occurred.

Johan

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: order of classvars changed after load

Hi Richard,

Thanks for your reply.

I was indeed surprised because I never noticed this in the past.

This is in a 2.4.4.1 stone. We are working on migrating everything to 3.2.

So, that should then probably be an issue of the past soon :)

Johan

On 19 May 2016, at 21:00, Richard Sargent via Glass <[hidden email]> wrote:

Since the class variables are held in a Dictionary, there really is no
"order", per se. While the class creation method may require an Array
argument, the order implied by the collection is not preserved.

If you look at the implementation of
#'subclass:instVarNames:classVars:classInstVars:poolDictionaries:inDictionary:newVersionOf:description:options:',
you will see that it tests for equivalency of the new definition to the
existing one. There have been changes in recent times to this mechanism in
order to reduce/eliminate the number of cases in which a new class version
is created unnecessarily. I think this was in one of the 3.2 releases, but I
don't recall which one.

What version of GemStone are you using?

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: order of classvars changed after load

In reply to this post by GLASS mailing list

Johan,

2.4.4.1 _is_ using an older version of Monticello than is used in 3.x ...

In 2.4.4.1 the asDefinition method sorts the class var names, but the
MCClassDefinition does not, which can lead to the condition where a diff
detects a difference between the package and image when in reality there
is no difference ... re-writing the mcz file may write the class vars in
sorted order and future compares might work correctly then ...

In 3.x the MCClassDefinition also sorts the class var names, so for
comparison you will be comparing sorted names for the image and the
package ... rendering the order that is saved in the mcz file immaterial ...

Dale

On 05/19/2016 12:08 PM, Johan Brichau via Glass wrote:

> Hi,
>
> I noticed a class getting a new class version when there had only been changes to class methods on a class.
> After investigation, it’s because the order of class variables seemingly changed
> from:
> classVars: #( ObjectsForKeyword ObjectsForScope ObjectTestsForScope PropertiesForKeywords)
> to:
> classVars: #( ObjectTestsForScope ObjectsForKeyword ObjectsForScope PropertiesForKeywords)
>
> However, the already loaded mcz file and the new mcz file for the package of this class have the same ordering (the last one) defined.
> When I use Monticello to check for ‘changes’ in the image with respect to the current loaded mcz, it reports the changed class variable ordering.
> However, merging the new mcz into the image does not detect these changes, only a ‘full load’ triggers the setting of a new class version.
>
> Summarizing, it seems the class definition in the image has a different class variable ordering defined than what was/is in the mcz file.
>
> Is there any ‘class var reordering’ logic going in during such loads? Not sure if I can reproduce this, because it’s a bit hard to find out when this class var order change would have occurred.
>
> Johan
>
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass