What are the expected semantics of changing a method in a class?

[ltratt]

Consider this program:

mutate_methods = (
    run = (
        mutate_methods methods at:2 put: #a.
        self f.
    )

    f = ( ^#b. )
)

[There is obviously a fragile assumption here that the f is the second method in methods, but let's not worry about that for the time being.]

On Java SOM it crashes on the self f call:

Exception in thread "main" java.lang.ClassCastException: class som.vmobjects.SSymbol cannot be cast to class som.vmobjects.SInvokable (som.vmobjects.SSymbol and som.vmobjects.SInvokable are in unnamed module of loader 'app')

which makes sense. However this seemingly inconsequential variation:

mutate_methods = (
    run = (
        self f.
        mutate_methods methods at:2 put: #a.
        self f.
    )

    f = ( ^#b. )
)

does not crash, presumably because the first self f call populates an inline cache which is not invalidated when the methods Array is mutated.

I assume that this is probably not the intended semantics for this second program (or perhaps it is?), but I'm not sure if e.g. a) SOM should notice the method change b) forbid chnages to the methods Array (e.g. via some sort of "this Array can't be altered?"). Any thoughts?

[smarr]

Thoughts: this is an unsatisfactory situation and reflection is considered unsafe in all SOM implementations.

I believe it is an example of "We know" how to make it fast and correct, and thus, noone ever bothered with it...

In Smalltalk, one would invalidate the caches. At least some Smalltalks assume they are used by "responsible programmers" and put the burden on the programmer by having an explicit API for invalidation: a flushCache primitive http://www.mirandabanda.org/bluebook/bluebook_chapter29.html
It's typically called by the "compiler" or method dictionary implementation.
Another reason why Smalltalk is an inherently unsafe language...

I am not entirely sure who added the lookup caching in SOM. Looking at the available code history it may have involved @mhaupt or @krono, but in the end, I am the one to blame for the current situation.

The "easy" thing to do would be to wrap the method array with something that invalidates all caches on write. In fast systems, one wants a more fine-grained approach, e.g. only removing relevant cache entries.

Currently, none of the SOMs do that. Reflection is simply not used in a mutating way.

[ltratt]

I guess there are two questions that we can tease apart here:

1. What are the intended semantics. I think you're saying that SOMs should automatically crash on the second of the two examples I gave without the user having to do anything else? [i.e. I don't think you're saying that flushCache is a good idea?]

2. How to make the intended semantics fast.

[smarr]

In an ideal world, reflective changes would be safe.

This may include an exception when putting a non-callable object into the method array.
It should likely automatically invalidate lookup caches, as class loading in Java does. Java being an example for a safe language here...

[ltratt]

Can we choose one of those models so that I can implement it? :p

[smarr]

Sure!

[ltratt]

I probably deserved that ;)

I will definitely invalidate caches. I'm not sure about the "raise an exception when something incorrect is put in there", because that makes Arrays appear to behave differently in ways that users can't reflect on (i.e. if I pass you an array, you can't tell if putting a symbol in it will bork until you put a symbol in it). But if you tell me that's the SOM way then I will do it!

[smarr]

Yes, invalidating caches is the best first step :)

[krono]

For the record, CSOM did not have any lookup cache and both snippets crash at the second invocation of #f.