Hi Levente,

On Fri, Oct 9, 2020 at 4:04 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:

> Hi Eliot,
>
> On Fri, 9 Oct 2020, Eliot Miranda wrote:
>
> > Hi All,
> >
> >     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 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.
>
> In my opinion, it would be better to get rid of #assert:equals: and
> #assert:equals:description:. Many find the order of its arguments
> confusing, and they are only good to help tracking down what failed.
> If #assert: could give information about it's argument: the source code
> and probably the values of the variables in it, then #assert:equals: would
> simply become unnecessary.
>

I couldn't agree more.  I *hate* assert:equals: being, for me, the wrong
way round.  We would need to provide an abstraction around extracting the
parse tree for an argument, which shouldn't be too hard.  Let me take a
look at this and see if I can provide something simple and robust.

>
> For example
>
> | x y |
> x := 'foo'.
> y := 1.
> self assert: x = y.
>
> would signal an exception with the message 'Assertion failed: x = y (x =
> ''foo'', y = 1)' instead of just 'Assertion failed'.
>
>
> Levente
>

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