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