Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ForeignObject does not support shallowCopy/deepCopy #153

Open
janehmueller opened this issue Dec 6, 2021 · 6 comments
Open

ForeignObject does not support shallowCopy/deepCopy #153

janehmueller opened this issue Dec 6, 2021 · 6 comments
Assignees
Labels

Comments

@janehmueller
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

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).

@janehmueller janehmueller changed the title ForeignObject does not support shallowCopy ForeignObject does not support shallowCopy/deepCopy Dec 6, 2021
@fniephaus
Copy link
Member

Do you have other examples where copying should be supported?

@janehmueller
Copy link
Contributor Author

janehmueller commented Dec 7, 2021

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:

  • To draw morphs, I register events, which include a callback symbol and receiver for that symbol.
  • When drawing a morph, one can use the halo to duplicate the morph. This triggers a deepCopy on the morph.
  • Due to the deepCopy, the registered events on the morph are copied. This includes the receiver for each event.
  • The receiver object may store a foreign object as instance variable or store another Smalltalk object as instance variable, which then stores a foreign object as instance variable. This chain can continue over multiple references, since Squeak is creating a deep copy.
  • If at any point in this chain a Smalltalk object stores a foreign object as instance variable, the deepCopy fails
  • Example foreign objects in my case are an instance of a JComponent subclass and an instance of a custom Java class.

@fniephaus
Copy link
Member

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?

@fniephaus fniephaus self-assigned this Dec 7, 2021
@janehmueller
Copy link
Contributor Author

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants