Hi Marcel,

On Thu, Apr 23, 2020 at 3:15 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi Eliot.
>
> Please find attached a change set. Like this? Here are some examples:
>
> array := #(1 2 3).
>
> ModificationForbidden
> for: array
> send: #showln:
> to: Transcript.
>
> ModificationForbidden
> for: array
> send: (MessageSend receiver: Transcript selector: #showln:).
>
> "Try out."
> array at: 1 put: #foo.
>

Yes, this looks good.  Exactly the kind of thing. The only issue now is
what is a convenient signature for the message send in ManagedObjects.  We
should consult with the GemSTone folks and perhaps look at the VisualWorks
code.  I'm cc'ing Martin McClure for comment.

Best,
> Marcel
>
> Am 23.04.2020 01:50:42 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
> Hi All,
>
> On Wed, Apr 22, 2020 at 10:59 AM tim Rowledge <tim at rowledge.org> wrote:
>
>>
>>
>> > On 2020-04-22, at 3:20 AM, Marcel Taeumel <marcel.taeumel at hpi.de>
>> wrote:
>> >
>> > Hi all!
>> >
>> > So, we make ModificationForbidden a (resumable) Error for now? Is this
>> the conclusion?
>>
>
> Yes, I hope so :-)
>
>
>>
>> It's a super-low-level error that ought to be handled really really
>> closely to where the error was raised. As Eliot mentioned, the VM can't
>> know the circumstances and just raises it; the the closest possible handler
>> should be in place that *does* know the circumstances. That way Chris gets
>> to spot that is it a database issue and handle things properly, including
>> likely raising a new error for higher level code.
>>
>
> As I've already mentioned what one can do, and the VisualWorks version
> does do, for GemStone-style persistence, as add behavior to the exception
> so one can specify a per-object response.
>
> 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.
> So can we please stop wasting time discussing this and get on with
> implementing it?  The GemStone folks have understood how to manage
> ModificationForbidden for years and the use of it has been in production.
> We simply need to catch up.  We're nearly there.
>
> Please don't make me explain this idea once again ;-)
>
> >
> > Given having a handler really close to the source, perhaps we are better
> off keeping it non-resumable and using one of the other approaches to
> continuing like #retryUsing: (ExceptionTester>>#simpleRetryUsingTest is the
> only example in the clean image) ?
>
>>
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Strange OpCodes: BFM: Branch on Full Moon
>>
> _,,,^..^,,,_
> best, Eliot
>
> _,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200423/ea03e338/attachment.html>