Hi Tony,


> Anyway, having it by default be the case that Workspaces' code environments be TestCases seems very sensible to me.


<http://www.hpi.de/>
What do you mean by this? Such a TestCase receiver environment should definitively be not the default, this would be very confusing!

> "Assertions of invariants in production code [as opposed to just in testing code] are useful. But they MUST BE LEFT ACTIVE IN PRODUCTION CODE because otherwise it's like wearing a seatbelt only while you're on your own driveway, and taking it off as soon as you're on the street."

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? :-)

Best,
Christoph
________________________________
Von: Tony Garnock-Jones <tonyg at leastfixedpoint.com>
Gesendet: Freitag, 9. Oktober 2020 16:33:12
An: The general-purpose Squeak developers list; Thiede, Christoph
Betreff: Re: [squeak-dev] assert:equals: in Object

On 10/9/20 2:34 PM, Thiede, Christoph wrote:
> Hi Eliot, Hi Marcel, -1 from my side for this change. :-)

Me too. I think it's almost a case of Gun>>draw vs Shape>>draw --
assert: in Object is for invariant-specification.

> Instead, we might miss some proper tooling for your use case, Eliot.
> Why can't we exchange the class of a Workspace's receiver?

I really like this line of thinking! I've been mulling over the idea of
having an ActorWorkspace that exists within the context of a running
Actor so it can react to events, "crash", etc. (It makes sense in
context -- Erlangish (and Syndicateish) actors are deeper participants
in their ecosystems than vanilla Actors are...)

Anyway, having it by default be the case that Workspaces' code
environments be TestCases seems very sensible to me.

I also wanted to respond to this:

> 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,

I wanted to make sure we are all on the same page by suggesting a
clarification here. I think, Christoph, that you *should* have meant :-)
something like:

"Assertions of invariants in production code [as opposed to just in
testing code] are useful. But they MUST BE LEFT ACTIVE IN PRODUCTION
CODE because otherwise it's like wearing a seatbelt only while you're on
your own driveway, and taking it off as soon as you're on the street."

Hopefully I'm right! :-)

It just alarmed me a bit to see discussion of making the same mistake C
makes, namely compiling away assertions in "release" builds, which is
where you need them most...

Cheers,
  Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201009/00a48a20/attachment.html>