<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Hi Tony,</p>
<p><br>
</p>
<p>> <span style="font-size:12pt">Anyway, having it by default be the case that Workspaces' code </span><span style="font-size:12pt">environments be TestCases seems very sensible to me.</span></p>
<div><br>
</div>
<p></p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" target="_blank" rel="noopener noreferrer" id="LPNoLP"><font size="2"><span id="LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">What do you mean by this? Such a TestCase receiver environment should definitively be not the default, this would be very confusing!</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">> <span style="font-size:12pt">"Assertions of invariants in production code [as opposed to just in </span><span style="font-size:12pt">testing code] are useful. But they MUST BE LEFT ACTIVE IN PRODUCTION </span><span style="font-size:12pt">CODE
because otherwise it's like wearing a seatbelt only while you're on </span><span style="font-size:12pt">your own driveway, and taking it off as soon as you're on the street."</span>
<div><br>
</div>
<div>Absolutely! All I wanted to avoid is that we introduce an SUnit extension on Object and no one notices that it is an extension method and then will misuse #assert:equals: as an assertion in production code - which would break his or her package if it is
installed in another environment that misses the SUnit package. Are we on the same page now? :-)</div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Tony Garnock-Jones <tonyg@leastfixedpoint.com><br>
<b>Gesendet:</b> Freitag, 9. Oktober 2020 16:33:12<br>
<b>An:</b> The general-purpose Squeak developers list; Thiede, Christoph<br>
<b>Betreff:</b> Re: [squeak-dev] assert:equals: in Object</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On 10/9/20 2:34 PM, Thiede, Christoph wrote:<br>
> Hi Eliot, Hi Marcel, -1 from my side for this change. :-)<br>
<br>
Me too. I think it's almost a case of Gun>>draw vs Shape>>draw --<br>
assert: in Object is for invariant-specification.<br>
<br>
> Instead, we might miss some proper tooling for your use case, Eliot. <br>
> Why can't we exchange the class of a Workspace's receiver?<br>
<br>
I really like this line of thinking! I've been mulling over the idea of<br>
having an ActorWorkspace that exists within the context of a running<br>
Actor so it can react to events, "crash", etc. (It makes sense in<br>
context -- Erlangish (and Syndicateish) actors are deeper participants<br>
in their ecosystems than vanilla Actors are...)<br>
<br>
Anyway, having it by default be the case that Workspaces' code<br>
environments be TestCases seems very sensible to me.<br>
<br>
I also wanted to respond to this:<br>
<br>
> Production assertions are a useful feature. But compared to SUnit, <br>
> they are not meant to fail at any time, and if they fail, they<br>
> should do so during development only,<br>
<br>
I wanted to make sure we are all on the same page by suggesting a<br>
clarification here. I think, Christoph, that you *should* have meant :-)<br>
something like:<br>
<br>
"Assertions of invariants in production code [as opposed to just in<br>
testing code] are useful. But they MUST BE LEFT ACTIVE IN PRODUCTION<br>
CODE because otherwise it's like wearing a seatbelt only while you're on<br>
your own driveway, and taking it off as soon as you're on the street."<br>
<br>
Hopefully I'm right! :-)<br>
<br>
It just alarmed me a bit to see discussion of making the same mistake C<br>
makes, namely compiling away assertions in "release" builds, which is<br>
where you need them most...<br>
<br>
Cheers,<br>
Tony<br>
</div>
</span></font>
</body>
</html>