> Compromise: can we introduce additional factory methods to make the LayoutFrame string both easy to grasp and evaluable? So it would satisfy both Marcel and Christoph?


> 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.


Well, as a LayoutFrame consists of 8 values, I'm afraid such a constructor would not provide a good readability in any way unless the arguments are grouped into rectangles, would it?



Regarding storing:

I just discovered #storeString - personally, I am satisfied with typing " storeString" and the <cmd>p at the moment ...


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Donnerstag, 19. September 2019 08:43:32
An: Alan Grimes via Squeak-dev
Betreff: Re: [squeak-dev] LayoutFrame>>#printOn:

> 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/20190923/b01d4fb9/attachment.html>