Serialization of singleton objects

[tinchodias]

Hello, thanks for Soil, it looks awesome. I have a question regarding singleton. Is it supported to indicate that a class implements singleton? this way, the materializer will access the unique instance to materialize that class.

I see a related implementation for SmalltalkImage and for SystemEnvironment: they use specialized "TypeCode" constants.

[tinchodias]

This was my failed intent:

Compiled in MySingleton:

soilSerialize: serializer
	serializer serializeBehaviorDescriptionFor: self

and, in class-side:

soilMaterialize: materializer
	^ self uniqueInstance

My workspace was:

arrayOfSingleton := (1 to: 50) collect: [ :_ | MySingleton uniqueInstance ].

bytes := arrayOfSingleton soilSerialize.
materialized := bytes soilMaterialize.
materialized asSet size. "50"

The expected size was 1, then I realized that materialization was resolved in FixedLayout>>#soilBasicMaterialize:with: so my hook wasn't used.

[tinchodias]

BTW, adding a custom entry in the codes of SoilTypeCodes class>>#initializeTypeCodes is very tempting as there are many free places!

[tinchodias]

I forgot to say I was on Soil v3. I am sketching an idea using the Soil serializer only. I mean, for the moment I didn't use other features of Soil.

For my prototype, it seems that this hacky solution is enough: I added to SoilSerializer this method:

registerObject: anObject
	objectIdTable add: anObject

The singleton object is a "well known object" that I register as internal object both in the serializer and the materializer before using them. This script shows it in action:

object := { EpMonitor basicNew. EpMonitor  current. EpMonitor basicNew }.
knownObjects := { EpMonitor  current }.

registry := SoilStandaloneObjectRegistry new.
serializer := SoilSerializer new.
knownObjects do: [ :each | serializer registerObject: each ].
bytes := serializer
	stream: ByteArray new writeStream; 
	externalObjectRegistry: registry;
	serialize: object.
materializer := SoilMaterializer new.
knownObjects do: [ :each | materializer registerObject: each ].
materialized := materializer
	stream: bytes readStream;
	externalObjectRegistry: registry;
	materialize.

object with: materialized collect: [ :a :b | a == b ].  "#(false true false)"

[MarcusDenker]

BTW, adding a custom entry in the codes of SoilTypeCodes class>>#initializeTypeCodes is very tempting as there are many free places!

Yes! This would be nice We have this issue tracker entry for that: #206
(I will add some comments there)

[MarcusDenker]

For Singletons, yes, it would be nice to have better support.

your registration approach seems to be a good first workaround.

What I wonder is if we can refactor the code a bit to have a hook that can be overrriden per class (without destroying performance).

[tinchodias]

Very interesting, thanks. My experiment extends Soil quite a lot and some of the decisions are very domain-specific (related to UI), so not sure what to do with it. Maybe just go deeper and copy the code and do not depend on Soil..! WIP

[MarcusDenker]

Yes, this is an option, especially considering how small the serializer is (in terms of lines of code). Being constrained by multiple very different usages for something simple often means that keeping it "one thing" starts to be more complex than the actual code twice.

And it is of course a bad idea to build something general when you are in an early stage of experimentation (as you even have no idea what you need in the end).

But it could be interesting (but maybe not from a practical use perspective, more a research one) to see what are the parts that would not change when we compare these two code bases? e.g. I somehow think that "object graph iteration" could, if abstracted correctly, be very general and fast.

[noha]

Can we close this. I really don't understand the rationale for special treatment of singletons. Singletons are a design approach in code and have less to do with persistence. Each object can overwrite #soilMaterialized: and then call something like #installAsSingleton. But as objects life cycles are tight to transactions to meaning of a singleton in soil is really questionable. We can talk about this but that is something I plan to do that is called "detached object" a special proxy that remembers its database address and therefor can escape the transaction shell and live longer