What should happen when a class's fields are mutated?

[ltratt]

What should the output of the following be?

instance_fields = (
    | x y |
    run = (
        | fds |
        fds := instance_fields fields.
        x := 1.
        y := 2.
        fds at: 1 put: #z.
        z println.
    )
)

Java SOM prints:

ERROR: Unable to resolve z

yksom would probably print the same if/when I implement the fields primitive. In a sense, it seems like reasonable behaviour to me, but I'm not sure if anyone has thought of this before and/or has opinions on what should happen.

[smarr]

In Squeak, you'll have to trigger the compiler manually to regenerate methods (tested on Squeak 5).
There's no "dynamic" binding/updating mechanism in place.

Pharo uses a more elaborate system, but I think the key there is that the return array is simply a snapshot of the class at that point.
So, any mutation to the array is without any effect.

I don't know what the right thing for SOM is.

Considering also #35, these things should ideally be following a consistent approach.

One option would be to say, yes, these methods always return snapshots, and any mutation is without effect on the actual system.

Another option would be to have methods bind dynamically to fields. Though, this would mean unknown fields raise #unknownGlobal:, which isn't ideal.
And your example wouldn't even allow for an approach that relies on recompilation of a method, but indeed needs a field lookup + invalidation at run time.

[ltratt]

Having thought about this a bit, I think a plausible course of action is to diverge from #35. The difference between fields and methods is that the former returns an array of names and the latter returns an array of methods. [IMHO, it would probably have made more sense for both to return an array of names because, but that might be a bigger change than you're willing to make (and perhaps not consistent with Smalltalk?).] I think mutations to the array of field names should be ignored because it would then turn SOM from a statically scoped language to a dynamically scoped language and I have learnt to be very wary of dynamic scoping over the years! Consider, for example, if I changed a field name from x to system: with dynamic scoping the program's bindings would change in a way that I don't think anyone could find helpful.