hpi-swa / trufflesqueak

A Squeak/Smalltalk VM and Polyglot Programming Environment for the GraalVM.
MIT License
286 stars 14 forks source link

ForeignObject does not support shallowCopy/deepCopy #153

Open janehmueller opened 2 years ago

janehmueller commented 2 years ago

Trying to copy Smalltalk objects that hold references to ForeignObjects (e.g., host Java values) fails, since ForeignObject does not support shallowCopy.

An example where the ForeignObject is a Java enum: image

fniephaus commented 2 years ago

Copying is not (yet) supported by the interop protocol. We've done some preliminary experiments with copying but need more use cases. Not all objects from other languages are copiable, so it's unclear what to do with them.

What do you expect from copying a Java enum? An error may be more intuitive than returning the same enum (although it's a singleton), right?

janehmueller commented 2 years ago

What do you expect from copying a Java enum? An error may be more intuitive than returning the same enum (although it's a singleton), right?

The example could be better, that is true. In the case of singleton classes an error is probably the better choice than not copying the object (since that points at a design issue).

fniephaus commented 2 years ago

Do you have other examples where copying should be supported?

janehmueller commented 2 years ago

Another use-case is using the duplication halo functionality on morphs in addition to registering events on morphs that point to objects that transitively store foreign objects as instance variables. Split up into parts my use-case/situation is as follows:

fniephaus commented 2 years ago

Ok good, here are some ideas for solving your issue:

  1. ForeignObject>>shallowCopy/deepCopy could return self. This would essentially disable coping across languages without throwing errors. Easy to do, good for compatibility, but potentially dangerous and probably not what we want.
  2. In Squeak, #copy is allowed to throw (see TraitDescription>>copy for example), so the ForeignObject copy methods could also always throw because copying is not (yet) supported by the interop protocol. Also easy to implement, but this wouldn't help you.
  3. We could define a ForeignSingleton which you could request via myForeignObject asSingleton with ForeignSingleton>>shallowCopy/deepCopy returning self (similar to ForeignArray). This would solve your problem but may be a bit overkill at this point.
  4. You could override #shallowCopy and #deepCopy in your classes that can be copied. In there, copy all Smalltalk objects as usual but keep fields that reference Java objects as they are, essentially special casing your foreign objects.

I'd probably go with option 4 for now. Could you give it a try and report your experience?

janehmueller commented 2 years ago

I agree. It sounds like option 4 is most sensible for me. I will try it out and report back (though it may take a while)