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