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