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.

Sign up for GitHub

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

Jump to bottom

Immutable objects #1035

Closed
cmelchior opened this issue Apr 15, 2015 · 2 comments
Closed

Immutable objects #1035

cmelchior opened this issue Apr 15, 2015 · 2 comments
Labels
T-Enhancement

Comments

@cmelchior
Copy link
Contributor

For frameworks like RxJava (#865) and others that work better with value type semantics, being able to specify a RealmObject as @Immutable would go a long way.

The semantics of this would be that marking a RealmObject as @Immutable would change the requirements of getters and setters to instead requiring a constructor with all fields + only getters. Like so

@Immutable
public class Foo extends RealmObject {
  private int bar;

  // Only legal constructor
  public Foo(int bar) {
    this.bar = bar;
  }

  public int getBar() {
    return bar;
  }
}

There are corner cases to consider though, eg. comparing a RealmObject with Standalone object, and possible others.
@fidergo-stephane-gourichon
Copy link

Having used Reactive Programming extensively for an application where thread safety is key, I'm thinking of a variant of this.

Need

  • In a highly reactive context, we need to represent data with immutable objects that can be safely passed through observables, whatever the consuming thread.
  • This is true also when the underlying data changes! In that case we need each time another immutable object representing the updated data.

Consequence

This calls for a different pattern: instead of instantiating one RealmObject descendant class and updating the fields when data changes, instantiate immutable RealmObject descendant class each time one is needed.

Optionally (because in my experience it was not necessary), a method can be called on such an object to see if it's still up-to-date.

This pattern could be implemented as an option, since it's not the default Realm behavior.

What do you think?

@cmelchior
Copy link
Contributor Author

This issue is beeing handled both here: #1208 and here #2538 . So closing this one.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
T-Enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@cmelchior @fidergo-stephane-gourichon