<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</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>Hi Marcel,</p>
<p><br>
</p>
<p>> <span style="font-size: 12pt;">still, it would be a shame if we would remove #assert:(description:) from Object, too. Then we couldn't document invariants in code anymore. So many trade-offs! :-O</span></p>
<div><br>
</div>
<p></p>
<div id="Signature">
<div id="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="divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="_rp_T4" id="Item.MessagePartBody">
<div class="_rp_U4 ms-font-weight-regular ms-font-color-neutralDark rpHighlightAllClass rpHighlightBodyClass" id="Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="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="_rp_T4" id="Item.MessagePartBody">Yes, I absolutely agree with that. Production assertions are a useful feature. But compared to SUnit, they are not meant to fail at any time, and if they fail, they should do so during development only, so I don't
think we have to optimize the meaningfulness of AssertionFailure messages (as opposed to TestFailures. See <a href="https://github.com/hpi-swa/smalltalkCI/issues/478" class="OWAAutoLink" id="LPlnk680133" previewremoved="true">https://github.com/hpi-swa/smalltalkCI/issues/478</a> :-)).</div>
<div class="_rp_T4" id="Item.MessagePartBody"><br>
</div>
<div class="_rp_T4" id="Item.MessagePartBody">> <span style="font-size: 12pt;">As you suggested, this could be better solved at the tool level. The "self" binding in workspaces has great potential. Bind it to an example test case, and </span><span style="font-size: 12pt;">this
would work. :-)</span></div>
<div class="_rp_T4" id="Item.MessagePartBody">
<div><br>
</div>
<div>I do indeed think there is much potential for new ideas (and this would finally show me a reason why variable bindings can be useful as an orthogonal concept to instance variables). But how can we avoid redundancy between inspectors and workspaces at this
point? How do you think about supporting dynamic bindings in every inspector's evaluator pane via opt-in? Or maybe add an item into Inspector's window menu, "convert to Workspace"?</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 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> Freitag, 9. Oktober 2020 14:40:43<br>
<b>An:</b> squeak-dev<br>
<b>Betreff:</b> Re: [squeak-dev] assert:equals: in Object</font>
<div> </div>
</div>
<div>
<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Christoph,
<div><br>
</div>
<div>still, it would be a shame if we would remove #assert:(description:) from Object, too. Then we couldn't document invariants in code anymore. So many trade-offs! :-O</div>
<div><br>
</div>
<div>As you suggested, this could be better solved at the tool level. The "self" binding in workspaces has great potential. Bind it to an example test case, and this would work. :-)</div>
<div><br>
</div>
<div>Best,</div>
<div>Marcel</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;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 09.10.2020 14:34:20 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:</p>
<div style="font-family:Arial,Helvetica,sans-serif">
<div id="divtagdefaultwrapper" style="font-size: 12pt;color: #000000;font-family: Calibri,Helvetica,sans-serif" dir="ltr">
<p>Hi Eliot, Hi Marcel,</p>
<p><br>
</p>
<p>-1 from my side for this change. :-)</p>
<p><br>
</p>
<p>If we start adding #assert:equals: and #assert:equals:description: on Object, it will be only a question of time until we will also discuss #deny:, #should:raise:, and all the other assertion selectors an object. And because it's not every object's purpose
to provide such testing mechanisms, this feels like a step in the wrong direction for me. Object is bloated enough already. Instead of defining new assertion selectors (which happens for the single purpose of improving exception messages as I suppose), we
should rather inspect the stack of an AssertionFailure/TestFailure to generate precise error messages.</p>
<p><br>
</p>
<p>Also, I am against defining these methods as extension methods because I would bet that someone (for example myself) would misinterpret them and assume they are part of the usual Object protocol, and suddenly you have a bunch of new dependencies from production
code to SUnit.</p>
<p><br>
</p>
<p>Instead, we might miss some proper tooling for your use case, Eliot. Why can't we exchange the class of a Workspace's receiver? Or thinking differently, why can't we support dynamic workspace bindings in every inspector (maybe opt-in)? Then you could just
inspect TestCase new, maximize the evaluator pane in the inspector, and e voilá you have a TestCase workspace.</p>
<p><br>
</p>
<p>Here are some references that might be related to this issue in some way:</p>
<p><a href="http://forum.world.st/Modifying-a-method-s-bytecodes-is-it-supported-tp5114421p5114435.html" class="OWAAutoLink" id="LPlnk818533" previewremoved="true">http://forum.world.st/Modifying-a-method-s-bytecodes-is-it-supported-tp5114421p5114435.html</a> (proposal
for Workspace variables)</p>
<p><a href="http://forum.world.st/The-Inbox-SUnit-ct-127-mcz-td5114709.html" class="OWAAutoLink" id="LPlnk910914" previewremoved="true">http://forum.world.st/The-Inbox-SUnit-ct-127-mcz-td5114709.html</a> (about the addition of new assertion selectors)</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph<br>
</p>
<div id="LPBorder_GT_16022468360390.16694891251849464" style="margin-bottom: 20px; overflow: auto; width: 100%; text-indent: 0px;">
<table id="LPContainer_16022468360370.7545936231936203" role="presentation" cellspacing="0" style="width: 90%; background-color: rgb(255, 255, 255); position: relative; overflow: auto; padding-top: 20px; padding-bottom: 20px; margin-top: 20px; border-top: 1px dotted rgb(200, 200, 200); border-bottom: 1px dotted rgb(200, 200, 200);">
<tbody>
<tr valign="top" style="border-spacing: 0px;">
<td id="TextCell_16022468360380.11077251484516881" colspan="2" style="vertical-align: top; position: relative; padding: 0px; display: table-cell;">
<div id="LPRemovePreviewContainer_16022468360380.6284541476428138"></div>
<div id="LPTitle_16022468360380.9201344657712431" style="top: 0px;color: rgb(36, 96, 118);font-weight: 400;font-size: 21px;font-family: wf_segoe-ui_light, "Segoe UI Light", "Segoe WP Light", "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif;line-height: 21px">
<a id="LPUrlAnchor_16022468360380.4118812243079446" href="http://forum.world.st/The-Inbox-SUnit-ct-127-mcz-td5114709.html" target="_blank" style="text-decoration: none;">Squeak - Dev - The Inbox: SUnit-ct.127.mcz</a></div>
<div id="LPMetadata_16022468360380.6257171793033918" style="margin: 10px 0px 16px;color: rgb(102, 102, 102);font-weight: 400;font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif;font-size: 14px;line-height: 14px">
forum.world.st</div>
<div id="LPDescription_16022468360390.4423381948790559" style="display: block;color: rgb(102, 102, 102);font-weight: 400;font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif;font-size: 14px;line-height: 20px;max-height: 100px;overflow: hidden">
The Inbox: SUnit-ct.127.mcz. Christoph Thiede uploaded a new version of SUnit to project The Inbox: http://source.squeak.org/inbox/SUnit-ct.127.mcz ==================== Summary...</div>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<br>
<p></p>
<p><br>
<br>
</p>
<div id="Signature">
<div id="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="divtagdefaultwrapper" style="font-family: Calibri,Arial,Helvetica,sans-serif;font-size: ;margin: 0">
<div><span style="font-size: 10pt;color: #808080"></span></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif;color: #000000"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
<b>Gesendet:</b> Freitag, 9. Oktober 2020 11:41:26<br>
<b>An:</b> squeak-dev<br>
<b>Betreff:</b> Re: [squeak-dev] assert:equals: in Object</span>
<div> </div>
</div>
<div>
<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Eliot,
<div><br>
</div>
<div>sure, SUnit could put those extensions into Object. I wouldn't want to have those outside SUnit, though. Not sure why. I only consider #assert: a useful tool even outside test cases. Just to document an invariant in a method.</div>
<div><br>
</div>
<div>Best,</div>
<div>Marcel</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;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 09.10.2020 10:24:58 schrieb Eliot Miranda <eliot.miranda@gmail.com>:</p>
<div style="font-family:Arial,Helvetica,sans-serif">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default" style="font-size: 14pt">Hi All,</div>
<div class="gmail_default" style="font-size: 14pt"><br>
</div>
<div class="gmail_default" style="font-size: 14pt"><span style="font-family: arial, sans-serif"> moving code from a test into a workspace and back is painful because Object does not implement assert:equals: or assert:equals:description: even though it implements
assert:description:. So one has to edit out the equals: moving to the workspace and edit it back in again on the way back. I'd like to suggest implementing Object>>assert:equals: and <span style="color: rgb(0,0,0);font-size: 12pt">Object>>assert:equals:description:
but I won't, because someone is bound to criticise it as being too green or ill considered or some other depressing BS.</span></span></div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div><span style="font-size: 10pt;border-collapse: separate"><span style="font-family: arial, sans-serif">
<div>_,,,^..^,,,_<br>
</div>
<div>best, Eliot</div>
</span></span></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>