Smalltalk › Squeak › Squeak - Dev

#printOn: as serialization format ... ;-)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

marcel.taeumel

#printOn: as serialization format ... ;-)

I don't think that's a good idea. We have #storeOn: and #readFrom: for that, right?

Thoughts? :-) Do you know of similar examples?

Best,

Marcel

Jakob Reschke

Re: #printOn: as serialization format ... ;-)

My youth experience in Lisp (and no, I'm not that old) tells me, sure the printed strings should be readable/evualuable expressions if possible. ;-)

IMHO if a "constructor expression" for the printed object is concise and legible enough, it makes a fine print string. Why not?

In the example you showed, we can discuss about coupling though. This implementation depends on the stability and parseability of the print string implementation of other objects...

Marcel Taeumel <[hidden email]> schrieb am Di., 17. Sep. 2019, 16:44:

I don't think that's a good idea. We have #storeOn: and #readFrom: for that, right?

Thoughts? :-) Do you know of similar examples?

Best,
Marcel

marcel.taeumel

Re: #printOn: as serialization format ... ;-)

There is no #readFromPrintString: to cope with changes... So, de-serialization code can be everywhere...

Best,

Marcel

Am 17.09.2019 17:27:58 schrieb Jakob Reschke <[hidden email]>:

My youth experience in Lisp (and no, I'm not that old) tells me, sure the printed strings should be readable/evualuable expressions if possible. ;-)

IMHO if a "constructor expression" for the printed object is concise and legible enough, it makes a fine print string. Why not?

In the example you showed, we can discuss about coupling though. This implementation depends on the stability and parseability of the print string implementation of other objects...

Marcel Taeumel <[hidden email]> schrieb am Di., 17. Sep. 2019, 16:44:
I don't think that's a good idea. We have #storeOn: and #readFrom: for that, right?

Thoughts? :-) Do you know of similar examples?

Best,
Marcel

marcel.taeumel

Re: #printOn: as serialization format ... ;-)

On second thought, #storeOn: and #readFrom: seem not *that* closely related ... Then, there is Object >> #readFromString:. And there are several implementations of #storeOn: that make use of #printOn: ...

> IMHO if a "constructor expression" for the printed object is concise and legible enough, it makes a fine print string. Why not?

Sure, using #storeOn: in #printOn: implementation seems fine. But the other way around? #printOn: is for the human eye, right? #storeOn: is for the machine ...

Best,

Marcel

Am 17.09.2019 17:50:21 schrieb Marcel Taeumel <[hidden email]>:
There is no #readFromPrintString: to cope with changes... So, de-serialization code can be everywhere...

Best,
Marcel

Am 17.09.2019 17:27:58 schrieb Jakob Reschke <[hidden email]>:

My youth experience in Lisp (and no, I'm not that old) tells me, sure the printed strings should be readable/evualuable expressions if possible. ;-)

IMHO if a "constructor expression" for the printed object is concise and legible enough, it makes a fine print string. Why not?

In the example you showed, we can discuss about coupling though. This implementation depends on the stability and parseability of the print string implementation of other objects...

Marcel Taeumel <[hidden email]> schrieb am Di., 17. Sep. 2019, 16:44:
I don't think that's a good idea. We have #storeOn: and #readFrom: for that, right?

Thoughts? :-) Do you know of similar examples?

Best,
Marcel

Nicolas Cellier

Re: #printOn: as serialization format ... ;-)

It's more something like Compiler evaluate: self storeString.

storeString generates a Smalltalk expression that reconstruct an equivalent object...

(equivalent to be defined, we know it cannot be =, thanks to things like Float nan)

Beware, storeString capability is VERY limited.

It does not cope with arbitrary graphs..

The byteCode limits are rapidly exhausted for complex Objects (cannot be evaluated back).

It rapidly becomes illegible.

The legacy application i wrote in the 90s had support for storing large (circular) objects in chunks, so that we could use something like (self storeString fileIn).

The chunks would set a variable that would be reused in later chunks (bottom up)

I extended the fileIn capability to use a namespace (like in workspace).

Otherwise, fileIn currently would fill Undeclared I think...

The generated code would have been something like:

rectangle1 := 0@0 extent: 20@10!

orderedCollection1 := #(1 4 2) asOrderedCollection!

myObject1 := MyObject collection: orderedCollection1 in: rectangle1! "what's this thing???"

rectangle2 := 0@0 extent: 40@10!

etc...

I went thru generating an AST rather than direct String because it's then possible to get better formatting.

I could then use this format for transcribing user interactions into an ActionScript (extract a program skeleton from user interaction...).

Most objects did have to redefine their own storeASTon: astBuilder so as to obtain a readable AST (better than instVarAt:put: and basicAt:put:)

The decision to create a chunk or not could be deferred (avoid a chunk if the object is used once, and can be constructed by a single expression, and containing expression does not exceed bytecode limits).

I found this option much more scalable than binary format in long term maintenance, because the backward compatibility support just mean supporting a legacy set of constructor messages. I have experimented loading 15 years old objects that did have completely changed their shape in between:)

Load time was sure longer than binary format, but bearable.

Of course, executing an arbitrary program sounds such a dull thing to ayatollahs of security nowadays ;) It would require sandboxing etc...

Le mar. 17 sept. 2019 à 18:11, Marcel Taeumel <[hidden email]> a écrit :

On second thought, #storeOn: and #readFrom: seem not *that* closely related ... Then, there is Object >> #readFromString:. And there are several implementations of #storeOn: that make use of #printOn: ...

> IMHO if a "constructor expression" for the printed object is concise and legible enough, it makes a fine print string. Why not?

Sure, using #storeOn: in #printOn: implementation seems fine. But the other way around? #printOn: is for the human eye, right? #storeOn: is for the machine ...

Best,
Marcel

Am 17.09.2019 17:50:21 schrieb Marcel Taeumel <[hidden email]>:
There is no #readFromPrintString: to cope with changes... So, de-serialization code can be everywhere...

Best,
Marcel

Am 17.09.2019 17:27:58 schrieb Jakob Reschke <[hidden email]>:

My youth experience in Lisp (and no, I'm not that old) tells me, sure the printed strings should be readable/evualuable expressions if possible. ;-)

IMHO if a "constructor expression" for the printed object is concise and legible enough, it makes a fine print string. Why not?

In the example you showed, we can discuss about coupling though. This implementation depends on the stability and parseability of the print string implementation of other objects...

Marcel Taeumel <[hidden email]> schrieb am Di., 17. Sep. 2019, 16:44:
I don't think that's a good idea. We have #storeOn: and #readFrom: for that, right?

Thoughts? :-) Do you know of similar examples?

Best,
Marcel