Hi Christoph,

Magma does not depend on ModificationForbidden.  My participation in this
discussion was merely for my own learning, to try to overcome my skepticism
about ModificationForbidden.  Changing its superclass shouldn't affect
Magma at all.  Whether Magma will be able to make use of it is still up in
the air.  Please feel free to integrate what you and the other folks
interested in this decide is best.

Thanks!
  Chris

On Thu, Sep 24, 2020 at 4:09 AM Christoph Thiede <
christoph.thiede at student.hpi.uni-potsdam.de> wrote:

> Hi Chris, hi all,
>
> after months of stagnation, I'd like to bring up this open discussion
> again.
> IMO the current situation in the Trunk is still buggy and the last thing we
> want developers to have to care about. For example, I recently crashed a
> number of smalltalkCI builds again because some method raised a
> ModificationForbidden, which the test runner, obviously, was not prepared
> for ...
>
> From what I can see, the only problem with my proposal that resists still
> in
> the inbox, Kernel-ct.1321, is related to Chris' Magma implementation. I
> want
> to respect this use case (and actually, learning a bit more about Magma is
> already on my long, long list of nice-to-do stuff), but I have to agree
> with
> other people saying that ModificationForbidden is a very low-level error
> and
> should not need any special treatment. For this reason, I also think that
> Marcel's changeset is a bit over-engineered for the Trunk, given the
> particular fact that we do not have plans for any user of ManagedObjects in
> the Trunk.
>
> Chris, did anything happen on your end regarding the handling of
> ModificationForbidden in Magma? Iirc you mentioned recently that you have
> reached some kind of feature completeness in your project. Can't we just
> merge Kernel-ct.1321 for now and resolve this discussion until some new use
> case arises? For Magma as an external project (still without being familiar
> at all with its design), I don't understand what would be wrong with
> handling such exceptions using #on:do:, this would totally suffice to
> circumvent the #defaultAction implementation. If you do not have the
> possibility to install an exception handler or a ToolSet, you could still
> place an extension override method in ModificationForbidden and
> (conditionally) inject your custom handling logic there.
>
> What do you think? I would like to finally get ahead with this issue! :-)
>
> Best,
> Christoph
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200924/fc2a8dde/attachment.html>