<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>> <span style="font-size: 12pt;">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?</span></p>
<div><br>
</div>
<p></p>
<p>> <span>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.</span></p>
<p><span><br>
</span></p>
<p><span>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?</span></p>
<p><span><br>
</span></p>
<p><span><br>
</span></p>
<p><span>Regarding storing:</span></p>
<p><span>I just discovered #storeString - personally, I am satisfied with typing " storeString" and the <cmd>p at the moment ...</span></p>
<p><span><br>
</span></p>
<p>Best,</p>
<p>Christoph</p>
<div id="Signature">
<div name="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
<b>Gesendet:</b> Donnerstag, 19. September 2019 08:43:32<br>
<b>An:</b> Alan Grimes via Squeak-dev<br>
<b>Betreff:</b> Re: [squeak-dev] LayoutFrame>>#printOn:</font>
<div> </div>
</div>
<div>
<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
> tpr: <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">My advice would be to not to try to push either too far. It will only cause pain...</span>
<div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br>
</span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Exactly. :-)</span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br>
</span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> jr: </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Compromise: can we introduce additional factory methods to make the LayoutFrame string both easy
to grasp and evaluable?</span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br>
</span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">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.</span></span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br>
</span></span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">> jr: </span></span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">If you do that please don't name it "store it". It would be totally non-obvious
what such an action would do.</span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br>
</span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">That's right. Unless we copy that string directly to the clipboard? :-D Let's discuss that idea in another thread.</span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br>
</span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div>
<div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div>
<div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 18.09.2019 20:33:35 schrieb tim Rowledge <tim@rowledge.org>:</p>
<div style="font-family:Arial,Helvetica,sans-serif">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.<br>
#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.<br>
#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.<br>
<br>
My advice would be to not to try to push either too far. It will only cause pain...<br>
<br>
tim<br>
--<br>
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim<br>
We can rescue a hostage or bankrupt a system. Now, what would you like us to do?<br>
<br>
<br>
<br>
</div>
</blockquote>
</div>
</div>
</body>
</html>