On Wed, Sep 30, 2020 at 12:59 PM David T. Lewis <lewis at mail.msen.com> wrote:

> Changing the subject line to ask the question directly.
>
> Can Kernel-ct.1321 be merged into trunk now?
>

I have no objection.

>
> See below and prior discussions.
>
> Thanks,
> Dave
>
>
> On Wed, Sep 30, 2020 at 05:29:43PM +0000, Thiede, Christoph wrote:
> > > I think there was an inbox submission a while back that could be
> merged.
> >
> >
> > Here it is: Kernel-ct.1321<
> http://forum.world.st/The-Inbox-Kernel-ct-1321-mcz-td5114734.html> ????
> >
> >
> > Best,
> >
> > Christoph
> >
> > ________________________________
> > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von David T. Lewis <lewis at mail.msen.com>
> > Gesendet: Mittwoch, 30. September 2020 19:26:30
> > An: The general-purpose Squeak developers list
> > Betreff: Re: [squeak-dev] Why is ModificationForbidden not an Error?
> >
> > I am not involved in this discussion, but if I understand the
> conversation
> > there is no longer any disagreement about what needs to be done, so we
> > just need to make it happen in trunk. I think there was an inbox
> submission
> > a while back that could be merged.
> >
> > +1000 for bringing this issue to a resolution, and thanks Christoph for
> > moving it forward.
> >
> > Dave
> >
> > On Wed, Sep 30, 2020 at 05:43:57AM -0700, Eliot Miranda wrote:
> > >
> > >
> > > > On Sep 30, 2020, at 3:48 AM, Thiede, Christoph <
> Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
> > > >
> > > > ???
> > > > Alright, anyone having any new opinion about this? Let's make a
> decision! :-)
> > > >
> > >
> > >
> > > I don???t see how it can be other than an error.  If one attempts to
> modify a literal that is an error. If one attempts to modify a read-only
> object then that is an error, unless some smart system is overloading
> read-only-ness to implement a read barrier.
> > >
> > > > Best,
> > > >
> > > > Christoph
> > > >
> > > > Von: Chris Muller <asqueaker at gmail.com>
> > > > Gesendet: Donnerstag, 24. September 2020 21:33:27
> > > > An: The general-purpose Squeak developers list; Thiede, Christoph
> > > > Betreff: Re: [squeak-dev] Why is ModificationForbidden not an Error?
> > > >
> > > > 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 ...
> > >
> > > This makes no sense to me.  Test runners collect tests that error just
> as they collect tests that assert fail.  Why would a ModificationForbidden
> Another be considered an error?
> > >
> > >
> > >
> > > >> 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! :-)
> > >
> > > I don???t want yo build something that is incompatible with gemstone.
> Currently we don???t have their attention; Ogaro had thrrr attention.  So
> we have to do the work of ensuring that ModificationForbidden supports the
> Gemstone use case; it???s a very very important one.  on:do: is completely
> inadequate for this.  One needs a system wide exception handler where any
> ModificationForbidden is routed through a manager that is able to identify
> that the object in question is in fact being mapped to a database (or a
> remote system, or a breakout ring system etc).  But on:do: handlers are for
> specific flows of control (currently within a single thread) and cannot
> serve as system wide handlers.
> > >
> > > Here???s a simplified use case.  The programmer wants to be able to
> trace wherever in the system an object is modified.  It may occur in
> arbitrary processes, not just in the current flow of control.  To do this
> efficiently the programmer uses ModificationForbidden to catch a
> modification, log it, make the object readable, effect the modification,
> make the object read-only again and proceed.  This *cannot* be done with an
> on:do: handler.
> > >
> > > >>
> > > >> Best,
> > > >> Christoph
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> 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/20201001/e688aa25/attachment.html>