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

Immutable objects #1035

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

Comments

Projects
None yet
2 participants
@cmelchior
Copy link
Contributor

cmelchior commented Apr 15, 2015

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.

@cmelchior cmelchior added T:Enhancement P3 and removed P3 labels Apr 15, 2015

@fidergo-stephane-gourichon

This comment has been minimized.

Copy link

fidergo-stephane-gourichon commented Jun 14, 2016

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

This comment has been minimized.

Copy link
Contributor

cmelchior commented Jan 30, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment