> tpr: My advice would be to not to try to push either too far. It will only cause pain...

Exactly. :-)

> jr: Compromise: can we introduce additional factory methods to make the LayoutFrame string both easy to grasp and evaluable?

Since there can only be one implementation of #printOn: for a class, I am fine with somebody changing the implementation to make the string readable in a different way. Making it evaluable would be an objective measure for such readability. However, we have #storeOn: for that and so many #printOn:'s in the system are not evaluable.

> jr: If you do that please don't name it "store it". It would be totally non-obvious what such an action would do.

That's right. Unless we copy that string directly to the clipboard? :-D Let's discuss that idea in another thread.

Best,
Marcel
Am 18.09.2019 20:33:35 schrieb tim Rowledge <tim at rowledge.org>:
Perhaps I missed it in the huge raft of emails I got this morning, but I'd urge people to remember the history of #printOn: & #storeOn: and related methods.
#printOn: is expected to result in a displayable String that offers a description of the receiver that can be helpful in debugging or other simple 'remind what this is' scenarios.
#storeOn: is/was an early attempt at providing a String that could be selected and evaluated to recreate an identical object. It had and has massive problems with anything actually complex - cycles, large size, whatever. That's why serializers came to be.

My advice would be to not to try to push either too far. It will only cause pain...

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
We can rescue a hostage or bankrupt a system. Now, what would you like us to do?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190919/1be3aec9/attachment.html>