Inconsistent handling of classVariables/sharedVariables when using ShiftclassBuilder

[astares]

in traditional Smalltalk up to Pharo 11 we had class variables defined like

Object subclass: #EventManager
	instanceVariableNames: 'actionMap'
	classVariableNames: 'ActionMaps'
	package: 'System-Object Events-Base'

Now in Pharo 12 the fluid class definition had been activated and the same definition is shown as mentioning them as shared variables:

Object << #EventManager
	slots: { #actionMap };
	sharedVariables: { #ActionMaps };
	tag: 'Base';
	package: 'System-Object Events'

Although it is a little bit confusing that this is now named #sharedVariables instead of #classVariables it is even more ìnconsistent and confusing when one can retriev them via #classVariables

EventManager classVariables

but not via #sharedVariables when asking for the builder again:

EventManager classBuilder sharedVariables 

The result is surprisingly empty. I would have expected

EventManager classBuilder sharedVariables 

to return a collection including ActionMaps class var again for the mentioned example.

[Ducasse]

Indeed we should continue to change the API (this is more than 10 years that I'm waiting for that --- getting rid of classVariablesNames: and classVariables:.

[MarcusDenker]

The problem is that if we send #classBuilder/#classInstaller to a class, that builder is not pre-configured for that class.

classBuilder
		"Answer the object responsible of creating subclasses of myself in the system."

		^ self classInstaller new builder

with #classInstaller being the class of the installer, not an installer instance configured for that class.

I was looking into changing to have #classInstaller return an instance for that class, but

self class classInstaller 

is in many places used to avoid a global reference to the ClassInstaller, but we then use that installer not to change the class but to create a new class that has nothing to do with the class that we got the installer from.

A nice aspect is that we could change #classBuilder, as we never use it. But then #classBuilder would not be in sync with the installer that you get when asking a class for #classInstaller...

Thus: no that trivial as it looks