Abut writeOn: versus storeOn:

Hi 

I have the impression that it is a left over of the dataStream and that we can remove it.

Stéphane Ducasse wrote
> I saw that a couple of collections implement writeOn: in addition to
> storeOn: and I was wondering if someone knows
> the reason. My gut feeling is that this is somehow dead code.

#Part 1: Do we need writeOn:?


I did some digging, but there was nothing conclusive to my eyes, although I
"smelled" the same thing you did. I am documenting here in case it helps...

One of the implementors is ShortIntegerArray. Its comment says it "is an
array for efficiently representing integers in the 16bit range." Although
it's in the Balloon package, its only user (other than objects that
initialize it) seems to be FT2Outline.

The other is ArrayedCollection, which has this comment for #writeOn: "Store
the array of bits onto the argument, aStream.  (leading byte ~= 16r80)
identifies this as raw bits (uncompressed).  Always store in Big Endian
(Mac) byte order.  Do the writing at BitBlt speeds. We only intend this for
non-pointer arrays.  Do nothing if I contain pointers."

The header and mention of BitBlt make that comment seem similar to another
implementor, Bitmap>>#writeOn: - "Store the array of bits onto the argument,
aStream. A leading byte of 16r80 identifies this as compressed by
compressToByteArray (qv)."

Form and MatrixTransform2x3 are other implementors that seem related, as
graphics artifacts.

Then there is RunArray - a seeming outlier - and several Zinc classes.

The clearest case seems to be Zinc, which seems to have this as a domain
concept, and has senders and implementors.

Other than Zinc, there are very few senders of the message.

There is FLEncoder, which seems like it could be legitimate, but it sends
the message from #encodeBitmap:, which is itself not sent. Same for
Form>>#writeBitsOn: (no senders)

The final sender is MCDataStream.

#Part 2: What is the distinction between writeOn: and storeOn:?



Stéphane Ducasse wrote
> Because readOn: logic is the inverse of storeOn: and I was wondering what
> is the equivalent for writeOn:

I'm not sure that this part is correct. I think storeOn: is orthogonal, and
#readOn: seems like the inverse from a native English perspective (e.g.
Magritte uses the terms read/write), but there are no implementors of
#readOn: in P8.

There was a recent discussion about #storeOn: and whether it is still useful
on Discord general channel. The most illuminating comment was:
Martin McClure 12/01/2020
@svenvc @Esteban A. Maringolo #storeString and #storeOn: are Smalltalk-80.
Page 101 of the Blue Book says of storeString, "Answer a String
representation of the receiver from which the receiver can be
reconstructed." The representation is always Smalltalk source code, the
"reconstruction" is evaluation by the compiler.

Here are all the posts in chronological order:

svenvc 12/01/2020
For the sake of discussion, what is a useful store string (for some standard
class in the image) ?
 
Esteban A. Maringolo 12/01/2020
For me a "store string" is an expression that instantiates the receiver
back.
👍
 
SeanDeNigris 12/01/2020
For Morphs, off the top of my head, it’s actually really cool because you
can re-create more from a prototype
 
Esteban A. Maringolo 12/01/2020
But it's a weak serialization mechanism, or at least it is fragile.
[8:44 AM]
(recursions, etc.)
 
SeanDeNigris 12/01/2020
I also use it to generate code in Magritte. The store string for the
description is the expression that is returned from the descriptions getter
Serializing blocks is a tough problem in general. I went through a lot of
grief because fuel will let you serialized them but depends on the outer
context not having changed to rematerialize, even for clean blocks, with no
hook to fix things if it has changed, making data unloadable
 
Esteban A. Maringolo 12/01/2020
It should only serialize clean blocks or give you a way to resolve the
closures.

@Esteban A. Maringolo
For me a "store string" is an expression that instantiates the receiver
back.
 
svenvc 12/01/2020
yes, that is it, but by definition it means that it depends on the compiler.
there is also no real specification of what the output looks like (like
JSON, XML, STON, or any other textual/binary format). it feels quite weird.
 
Esteban A. Maringolo 12/01/2020
I don't ask for specification, but historically storeOn: aStream always was
"smalltalk" expressions.
[9:11 AM]
at least in my experience, and even "actual" use (not that I chose to use
it, but a customer does).
 
gcorriga 12/01/2020
#storeSting is useful when debugging, or when doing exploratory coding.
[10:24 AM]
e.g. I have a complex data structure, I can send #storeString to it to get a
text representation I can use e.g in a unit test.

Martin McClure 12/01/2020
@svenvc @Esteban A. Maringolo #storeString and #storeOn: are Smalltalk-80.
Page 101 of the Blue Book says of storeString, "Answer a String
representation of the receiver from which the receiver can be
reconstructed." The representation is always Smalltalk source code, the
"reconstruction" is evaluation by the compiler.
Of course not all objects can easily be represented by source code, so in
practice this message is most useful for objects that can be represented as
Smalltalk literals. IMO we should preserve the storeOn: semantics for those
objects, but other formats are more useful for general objects.

svenvc 12/01/2020
Maybe we should add some more documentation then, as well as some
illustrative unit tests/examples.
👍
2



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html