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