Open janehmueller opened 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?
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).
Do you have other examples where copying should be supported?
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:
JComponent
subclass and an instance of a custom Java class.Ok good, here are some ideas for solving your issue:
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.#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.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.#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?
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)
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: