> Then IMO we should follow suit.  For once I agree with them ;-)

Nooo ... :( I don't know their reasons, but inverting a long-existing convention from one day to another seems like a true nightmare to me. This would invalidate the semantics of every existing test case that was ever written for Squeak/Smalltalk.

Plus, IMHO it is often useful to order parameters by their complexity ascending (e.g., put blocks last) to provide a good writeability/readability of a message's senders. While the expected argument often is a constant, the actual argument mainly is the result of a possibly complex operation, e.g.:

self assert: 42 equals: (myComputer
    doComplexComputationWith: 6
    and: 7
    mode: #multiplyInt).

How would the opposite read like?

self assert: (myComputer
    doComplexComputationWith: 6
    and: 7
    mode: #multiplyInt) equals: 42.

IMO, much less comprehensible.

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
Gesendet: Dienstag, 13. Oktober 2020 04:02:48
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] assert:equals: in Object



On Mon, Oct 12, 2020 at 12:27 PM Jakob Reschke <forums.jakob at resfarm.de<mailto:forums.jakob at resfarm.de>> wrote:
Eliot Miranda-2 wrote
> - appealing to the SUnit community to reverse the order of arguments to
> assert:equals:, plus a rewrite rule that reversed the obvious cases where
> the first argument is a literal constant.

For what it is worth, Pharo has just swapped the parameters... which makes
all "portable" test cases awkward.

Then IMO we should follow suit.  For once I agree with them ;-)
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html



--
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201013/dadb7922/attachment.html>