Smalltalk › Squeak › Squeak - Dev

Why is ModificationForbidden not an Error?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

54 messages Options

123

David T. Lewis

Re: Why is ModificationForbidden not an Error?

Thanks Ron, I think that I suddenly understand the issue :-)

Dave

On Fri, Apr 24, 2020 at 02:37:52PM -0400, Ron Teitelbaum wrote:

> Hi all,
>
> I'd like to add some color here. I worked with Versant for many many
> years. This problem bites you so hard you need a tourniquet just to
> survive it.
>
> Imagine looking at your code and trying to understand why something that
> looks so simple is completely wrong! You spend a huge amount of time
> trying to understand why the code doesn't actually do what it SAYS it will
> do. How is this possible? You read and read, you start
> writing things down but no it is impossible. You feel like you must be
> missing something extremely simple or are just losing your mind. Then you
> decide ok I'll take this step by step and validate every message to see
> exactly where it breaks. You have been looking at this error for over 72
> hours straight because someone is standing over your shoulder waiting to
> ship the product they promised would be available a week ago.
>
> So you get to a method Integer fortyTwo. And it returns #(0) instead of
> #(42). What the hell is that!!!! The code says ^#(42)!!!!. You can see
> it right there!!! Then it hits you. I've been bit by a literal variable
> change! You add copy and now everything works just like you expected it
> to. Now you need to get the trounequat because after you kicked the trash
> can you split your knee on the table. Then you go to talk to your
> colleague and he falls asleep while you are talking to him and his head
> hits the keyboard. You ask your boss who looks nearly as bad as the
> comatose colleague what you should do and he says "Save the code!" So you
> save the code and roll your colleague under the table so nobody steps on
> him.
>
> This doesn't happen you think?? Well on Versant you couldn't even change
> the method if the database was holding onto the litteral! Trying to accept
> a method gave you a database error!!! Oh great fun that was!
>
> Some people have learned the hard way with litteral blood that copy is
> essential, and for those that haven't you can save them a lot of pain.
> Changing litterals without the copy is always wrong especially if it will
> eventually be stored in a database. Imagine doing direct manipulation on a
> litteral. Now try to explain what happened since the code never actually
> changed anything!!! How the hell did that happen!!
>
> Try it yourself and then imagine my barely open eyes trying in vain to
> understand what happened!
>
> Integer class >> fortyTwo
> ^#(42)
>
> Integer fortyTwo #(42)
> Integer fortyTwo at: 1 put: 0.
> Integer fortyTwo #(0)
>
> Go back and look at the method. Hasn't changed still says ^#(42). Good
> luck debugging that!
>
> I hope that adds some color around this issue. Ok back to your regularly
> scheduled program!
>
> All the best,
>
> Ron Teitelbaum
>
>
>
> On Fri, Apr 24, 2020 at 1:16 PM Eliot Miranda <[hidden email]>
> wrote:
>
> >
> >
> > On Apr 24, 2020, at 9:59 AM, Jakob Reschke <[hidden email]>
> > wrote:
> >
> > ???
> > Domain and "data storage" layers are intermixed here, hence the trouble
> > with the concept of read-only. If you don't want such a distinction of
> > layers by using different objects in the first place, then I suggest to at
> > least use separate protocols. So yes, use different managers for
> > different kinds of read-onliness. Your domain-specific layer can still
> > delegate to the VM write barrier if that works well. And different
> > applications can still access the same kind/layer of read-onliness, so
> > Eliot's proposal to have one registry for the VM write barrier handling
> > remains valid.
> >
> > I'd say each domain should also have an own exception class in this case.
> > As an implementation detail, it could inherit from the base
> > ModificationForbidden... or hide the concrete class behind an accessor.
> >
> >
> > No. That is unnecessary. The issue is to separate intercepting an
> > attempt to write to a read-only object from what happens in response to
> > that attempt. And that???s what the ManagedObjects/defaultAction mechanism
> > does. Attempts to write are caught and other objects handle what happens
> > in response.
> >
> > Thinking of this issue in the co text of exception handlers doesn???t make
> > sense. Writes happen all over the system, and not necessarily within the
> > dynamic extent of some computation. The exception handler is global. So
> > one won???t be able to establish exception handlers for all cases. Instead,
> > the global exception system dispatches a per-object-specific response
> > through ManagedObjects.
> >
> >
> >
> >
> > Marcel Taeumel <[hidden email]> schrieb am Fr., 24. Apr. 2020,
> > 12:10:
> >
> >> > But this means the DB is now occupying the use of the readOnly bit,
> >> not available for other applications or use-cases.
> >>
> >> Hmmm... ManagedObjects could be partitioned among multiple applications.
> >> For example, a game loading some save state could come across some
> >> read-only objects and then choses how to manage those. Another application
> >> could do this as well, not interfering with the first one. Both might be
> >> considered "small DB managers" so to say.
> >>
> >> Of course, that check "myDomainObject isReadOnlyObject" would become
> >> standard procedure for such DBs, wouldn't it?
> >>
> >> Best,
> >> Marcel
> >>
> >> Am 24.04.2020 05:26:56 schrieb Chris Muller <[hidden email]>:
> >>
> >>> So if the exception is unhandled, then before it raises an
> >>>> UnhandledError it checks an identity dictionary, which maps object to
> >>>> message, and if the read-only object that was the cause of the error is in
> >>>> the dictionary, instead the exception performs the message with the object
> >>>> as an argument. So a database layer can add the objects it is managing to
> >>>> the map in ModificationForbidden, and mark them as read-only. Then any and
> >>>> all attempts at modifying these objects will cause the database man ager to
> >>>> be notified.
> >>>>
> >>> So very simply we can have a pluggable solution that allows different
> >>>> clients to map the exception into different responses as desired.
> >>>>
> >>>
> >>> But an object in your db table could easily be an Array literal held by
> >>> a CompiledMethod, not expected to change, but persistent by reference
> >>> nonetheless. So if the application did then modify it accidentally,
> >>> instead of Forbidden protection, your DB manager would happily modify it.
> >>> It's this separation of use-cases is all what the question was about I
> >>> think, not a big deal, we've lived with unprotected CM literals for this
> >>> long already, and I've never needed WriteBarrier for anything other than a
> >>> DB.
> >>>
> >>>
> >>> Since objects get added to the collection intentionally the array
> >>> literal would not be added and hence the manager would not modify it.
> >>>
> >>
> >> How would the manager know not to add it? It can't be by checking
> >> #isReadOnlyObject, since that presents the same paradox -- requiring the
> >> manager to know the business of whatever other use-case has it set. If it
> >> assumed it was for CM-literal protection, it wouldn't add it, but what if
> >> it was just some debugging or something?
> >>
> >>
> >>> Your example is a straw man.
> >>>
> >>
> >>>
> >>> However, I still don't see the path for how to use this in a complex
> >>> multi-db Magma application with oblivious objects (e.g., Morphs). It's not
> >>> something any of the GemStone clients I consulted at as developer or DBA
> >>> ever had to contend with either, but perhaps not something you're
> >>> targeting. Squeak is a different animal... I will stay tuned here and
> >>> watch for the answers as they unfold...
> >>>
> >>>
> >>> The objects that get added to the wrote barrier management collection
> >>> get added by managers that want to manage specific objects, not arbitrary
> >>> objects. Can you see that a DB manager would add objects it has
> >>> materialized from the DB that it wanted to transparently write-back in
> >>> modification, and no others?
> >>>
> >>
> >> Yes, absolutely. The manager will get every ModificationForbidden signal
> >> under its code whether its meant for the DB or not. Existence in a global
> >> table means handle it, otherwise pass it up the stack. But this means the
> >> DB is now occupying the use of the readOnly bit, not available for other
> >> applications or use-cases.
> >>
> >> I hope this critique isn't taken to mean I don't think this isn't a good
> >> feature for the VM and image. I do. Everything is a balance of features
> >> and limitations. I'm still trying to determine whether Magma can benefit
> >> from this, and I have to get deeply critical to find the right decision. I
> >> will be following this feature closely, thanks for your patience with my
> >> questions.
> >>
> >> - Chris
> >>
> >>
> >>
> >
> >

Jakob Reschke

Re: Why is ModificationForbidden not an Error?

In reply to this post by Chris Muller-3

Am Fr., 24. Apr. 2020 um 23:56 Uhr schrieb Chris Muller <[hidden email]>:
>>
>> The fact that there is a helpful default handler for an exception does not (should not!) mean you can't catch it and do something more to your liking
>
>
> Only if you control the code. For Magma-like transparency, it must be able to operate on oblivious objects which have ZERO knowledge of any database or handlers. Cmd+s in an Inspector should be picked up and saved in the next DB commit, unless it's a CM-literal, in which case it should error immediately...
>

Hmm for this particular case I don't see the issue. Modification
through an inspector will create references to other objects, so to
run into ModificationForbidden here, you would have to modify a
composite literal object, which could only be an Array if I am not
mistaken. The elements of literal arrays are literals themselves (not
in the CompiledMethod-sense, but they are all immutable now, right?
think of nested arrays). So when you press Cmd+s, you will immediately
get the exception, before anything changes in the object. So the
database would not be affected by the error or the modification
attempt, right?

Or it would proceed immediately because it was registered so in the
object-specific handler supplied via the methods in Marcel's
changeset. Then things get modified and so they would be in the
database. Do you mean the exception could arise again in the database
code?

Jakob Reschke

Re: Why is ModificationForbidden not an Error?

I finally got around to read Marcel's changeset and the code that
signals ModificationForbidden. Now I see that resuming the
ModificationForbidden means to skip the modification and proceed with
the code ahead, not to do the modification despite the read-only state
as I assumed. Sorry.

Let me check my understanding. If there is a forbidden modification,
the only way to abort an operation via object handlers is to do a
non-local return eventually (handler is a block or signals another
exception). Because the defaultAction implies that the
ModificationForbidden exception will be resumed and you can only
control the resumption value, unless there is a non-local return
eventually. Is that correct? Then I'm thinking one would rather choose
to handle ModificationForbidden conventionally with on:do: if one
wishes to abort something. And use object handlers only for use cases
where you can actually do something about it.

In that case I'm wondering how an object database is actually going to
proceed from there. Copy, modify, record, become:, let resume? If the
answer is too long, just tell me I would have to read it up in the
literature. ;-)

Am Sa., 25. Apr. 2020 um 10:06 Uhr schrieb Jakob Reschke
<[hidden email]>:

>
> Am Fr., 24. Apr. 2020 um 23:56 Uhr schrieb Chris Muller <[hidden email]>:
> >>
> >> The fact that there is a helpful default handler for an exception does not (should not!) mean you can't catch it and do something more to your liking
> >
> >
> > Only if you control the code. For Magma-like transparency, it must be able to operate on oblivious objects which have ZERO knowledge of any database or handlers. Cmd+s in an Inspector should be picked up and saved in the next DB commit, unless it's a CM-literal, in which case it should error immediately...
> >
>
> Hmm for this particular case I don't see the issue. Modification
> through an inspector will create references to other objects, so to
> run into ModificationForbidden here, you would have to modify a
> composite literal object, which could only be an Array if I am not
> mistaken. The elements of literal arrays are literals themselves (not
> in the CompiledMethod-sense, but they are all immutable now, right?
> think of nested arrays). So when you press Cmd+s, you will immediately
> get the exception, before anything changes in the object. So the
> database would not be affected by the error or the modification
> attempt, right?
>
> Or it would proceed immediately because it was registered so in the
> object-specific handler supplied via the methods in Marcel's
> changeset. Then things get modified and so they would be in the
> database. Do you mean the exception could arise again in the database
> code?

Chris Muller-3

Re: Why is ModificationForbidden not an Error?

In reply to this post by Jakob Reschke

On Sat, Apr 25, 2020 at 3:06 AM Jakob Reschke <[hidden email]> wrote:

Am Fr., 24. Apr. 2020 um 23:56 Uhr schrieb Chris Muller <[hidden email]>:
>>
>> The fact that there is a helpful default handler for an exception does not (should not!) mean you can't catch it and do something more to your liking
>
>
> Only if you control the code. For Magma-like transparency, it must be able to operate on oblivious objects which have ZERO knowledge of any database or handlers. Cmd+s in an Inspector should be picked up and saved in the next DB commit, unless it's a CM-literal, in which case it should error immediately...
>

Hmm for this particular case I don't see the issue. Modification
through an inspector will create references to other objects, so to
run into ModificationForbidden here, you would have to modify a
composite literal object, which could only be an Array if I am not
mistaken.

Correct. And, the Inspector code doesn't know whether its a CM-literal or just a regular, should-be-updatable Array. It'll either be registered with a handler, or it won't.

The elements of literal arrays are literals themselves (not
in the CompiledMethod-sense, but they are all immutable now, right?
think of nested arrays).

No. From my understanding only the root Array is immutable, the nested ones aren't. This isn't related to the issue being raised, just answering your question..

So when you press Cmd+s, you will immediately
get the exception, before anything changes in the object. So the
database would not be affected by the error or the modification
attempt, right?

Or it would proceed immediately because it was registered so in the
object-specific handler supplied via the methods in Marcel's
changeset. Then things get modified and so they would be in the
database. Do you mean the exception could arise again in the database
code?

The above is what I'm trying figure out. My understanding is, if you registered a handler for the object, it'll run that, otherwise the defaultAction which is to open a debugger saying ModificationForbidden.

The challenge, at least from the way Magma is implemented, is at the point where it's time to register an Array with ManagedObjects, there's no way to know whether it's a CM-literal or not. But even that is independent of the fact the read-only bit is still exposed for modification by other use-cases. In a coordinated, frozen system like a GemStone business app, this can be managed. In a live system that might make use of dynamically loaded modules, it could be dangerous.

- Chris

Christoph Thiede

Re: Why is ModificationForbidden not an Error?

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

Carpe Squeak!

Chris Muller-3

Re: 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 <[hidden email]> 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

Eliot Miranda-2

Re: Debugger - Proceed button (was: Why is ModificationForbidden not an Error?)

In reply to this post by Jakob Reschke

On Apr 11, 2020, at 12:13 PM, Jakob Reschke <[hidden email]> wrote:

Think of this: you may not be able to reasonably proceed after an unresumable error without modifying the system or the context. But the IDE lets you do just that: you can change something on the stack in the debugger, or implement the missing method, then proceed and violà, you just reasonably proceeded from an otherwise unresumable error.

I suppose the methods you mentioned are recursive/repeating to allow for exactly that kind of workflow.

One should naturally be allowed to Proceed from the notifier window of a Halt or Warning.

Which leads us to the topic of exception-specific or context-specific buttons in the notifier once again. I don't remember which topic it was, but I wished for that already once during the last few months. Maybe it was the deprecation warnings and now we have an explanation how to deal with Warnings in the notifier and those text actions that allow to disable the warnings on the spot. And as always I'd like to point out that Common Lisp has a nice concept for responding to exceptions both automatically and interactively, with user-code-registered restart operations that can be invoked from the debugger: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html In Smalltalk you can already use #return, #retry, #resume etc in an exception handler, but you cannot access the handlers nicely from the debugger, and you cannot "resume somewhere along the way to the exception".

*1. Good points. Good analysis.

Am Sa., 11. Apr. 2020 um 16:38 Uhr schrieb Thiede, Christoph <[hidden email]>:

Just another thought: I see some confusion around the Proceed button in the debugger, and I felt the same confusion sometimes ago. Please forgive me for the sacrilege, but should we maybe question its general existence?

Depending on the domain, it actually performs a mix of #retry (made possible by the quite confusing recursive implementation of Object >> #at:, Object >> #doesNotUnderstand: and others, I did not yet found any other motivation than the Proceed button to use recursion here) and ignore (#resumeUnchecked:, especially useful for UnhandledWarnings and Halts). Would it be a reasonable goal to eliminate this button in the pre-debugger window and replace it with two buttons, Restart and Ignore? We could hide even hide the restart button if not appropriate (i.e., the exception is not an error).

What do you think?

And it would be great if anyone here could explain why Object >> #at: & Co. are recursive! :-)

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Samstag, 11. April 2020 16:32 Uhr
An: Chris Muller; The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Why is ModificationForbidden not an Error?

Hi all! Thank you very much for having this interesting discussion :-)

@Chris:

> > -1. :-) Warnings are Notifications,

> As are Errors. Right?

Nope, sorry ;-)

<pastedImage.png>

<pastedImage.png>

> The two main use cases of ModificationForbidden present opposite perspectives onto it. For "protection from accidentally modifying a literal in a CompiledMethod", I understand the inclination to make it an Error. However, for the context of db handling, [#markDirty + #resume] is normal processing, not an "error", and not even exceptional, either, so perhaps this is just a semantic irritation sensitivity on my part.. sorry.

> But if they want to use ModificationForbidden for a Write Barrier, they'll probably want to extricate it from Error in the handler:

>

> [ myDbApp doStuff ]

> on: ModificationForbidden

> do:

> [ : forbidden |

> forbidden object beWritableObject.

> forbidden resumptionValue: forbidden retryModificationNoResume.

> forbidden resume: forbidden resumptionValue ]

> on: Error

> do: [ : err | myDbApp logErrorAndNotifyUser ]

This clarification was very helpful for me. I was not aware of your second use case before.

In my opinion, we are talking about two completely different use cases for the same exception.

Literal protection is a low-level error, comparable to out-of-bounds things and primitive failures. You almost never do want to ignore or fix them.

Write barriers for #markDirty, on the other hand, sound like a domain-specific topic to me that should neither raise an error, nor eventually signal an UnhandledError, but be resumed automatically (unless handled differently) by a #defaultAction that removes the barrier (and additional handlers could, if desired, turn on some cache or so).

I have never dealt with Magma or any other DB framework for Smalltalk, but why do you (or would you) use these VM-based mechanisms for a high-level feature? Without knowing any details about your application, personally I would probably design an own exception (DirtyModification?) for that purpose. This would allow you to clearly distinguish between low-level errors ("whoops, I just made an attempt to change a read-only code literal") and higher-level exceptions (DirtyModification). If we would follow my proposal to raise ModificationForbidden from Object instead of Context, you could also consider to override #modificationForbiddenFor:at:put: in your database objects to raise DirtyModification instead of ModificationForbidden (in the same way as some classes override #error or #primitiveError).

However, focusing again on the literal protection aspect, I still don't see when the current default #resume behavior of ModificationForbidden would be ever helpful. MF >> #resume calls Exception >> #resume: which does nothing more than to return resumptionValue! When do we actually need this resumptionValue?

Why can't we design MF like the following:

#resume - not possible, will signal IllegalResumeAttempt

#retryModification - retries the modification and returns nothing special

#forceModification: - makes the object to modify writable, retries the modification and, optionally, makes the object read-only again

> If we don't want to break things (that are somehow wrong according to contemporary notion), we could make it a Warning in the Squeak 5.x release stream and turn it into an error with Squeak 6.0. That is: make it an Error today in Trunk, but if we would create a 5.4 release, we would have to remember changing it back... :-/

IIRC ModificationForbidden was introduced in 6.0alpha the first time?

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Nicolas Cellier <[hidden email]>
Gesendet: Samstag, 11. April 2020 11:16:00
An: Chris Muller; The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Why is ModificationForbidden not an Error?

In this case we might want specialized subclasses...

Le sam. 11 avr. 2020 à 03:45, Chris Muller <[hidden email]> a écrit :

I think so, because if you try to use it for something else, it'll get entangled with your application's standard error handling. Regular apps have error handling like:

[ myApp doStuff ] on: Error do: [ : err | myApp logErrorAndNotifyUser ]

and so for the use-case, Protect CompiledMethod Literals from Accidental Modification, inheriting from Error will allow the best backward compatibility with existing handlers.

But if they want to use ModificationForbidden for a Write Barrier, they'll probably want to extricate it from Error in the handler:

[ myDbApp doStuff ]

on: ModificationForbidden

do:

[ : forbidden |

forbidden object beWritableObject.

forbidden resumptionValue: forbidden retryModificationNoResume.

forbidden resume: forbidden resumptionValue ]

on: Error

do: [ : err | myDbApp logErrorAndNotifyUser ]

But now that I'm handling ModificationForbidden separately, what if I want Protect CompiledMethod Literals from Accidental Modification, too? I'm no longer handling correctly for that, because the handler has to assume they're signaled in the context of the DB use case and not the Protection use case.

- Chris

On Fri, Apr 10, 2020 at 12:06 PM tim Rowledge <[hidden email]> wrote:

> On 2020-04-09, at 6:55 PM, Chris Muller <[hidden email]> wrote:
>
> The two main use cases of ModificationForbidden present opposite perspectives onto it.

In that case perhaps we actually need two different signals?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Has an inferiority complex, but not a very good one.

Christoph Thiede

Re: Why is ModificationForbidden not an Error?

In reply to this post by Chris Muller-3

Alright, anyone having any new opinion about this? Let's make a decision! :-)

Best,

Christoph

Von: Chris Muller <[hidden email]>
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,

Thanks!

Chris

On Thu, Sep 24, 2020 at 4:09 AM Christoph Thiede <[hidden email]> 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

Carpe Squeak!

Eliot Miranda-2

Re: Why is ModificationForbidden not an Error?

On Sep 30, 2020, at 3:48 AM, Thiede, Christoph <[hidden email]> 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 <[hidden email]>
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 <[hidden email]> 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

David T. Lewis

Re: Why is ModificationForbidden not an Error?

>
>
> > On Sep 30, 2020, at 3:48 AM, Thiede, Christoph <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]> 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
> >>
> >

Christoph Thiede

Re: Why is ModificationForbidden not an Error?

> I think there was an inbox submission a while back that could be merged.

Here it is: Kernel-ct.1321 😊

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]> 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
> >>
> >

>

Carpe Squeak!

David T. Lewis

Can Kernel-ct.1321 be merged into trunk now? (was: Why is ModificationForbidden not an Error?)

Changing the subject line to ask the question directly.

Can Kernel-ct.1321 be merged into trunk now?

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 <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]> 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
> > >>
> > >
>
> >
>
>

Eliot Miranda-2

Re: Can Kernel-ct.1321 be merged into trunk now? (was: Why is ModificationForbidden not an Error?)

On Wed, Sep 30, 2020 at 12:59 PM David T. Lewis <[hidden email]> 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 <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]> 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

David T. Lewis

Re: Can Kernel-ct.1321 be merged into trunk now? (was: Why is ModificationForbidden not an Error?)

On Thu, Oct 01, 2020 at 11:40:16AM -0700, Eliot Miranda wrote:
> On Wed, Sep 30, 2020 at 12:59 PM David T. Lewis <[hidden email]> wrote:
>
> > Changing the subject line to ask the question directly.
> >
> > Can Kernel-ct.1321 be merged into trunk now?
> >
>
> I have no objection.
>

Done - thanks Christoph.

Dave

123