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

Drop/deprecate broken or unused features #43

Open
3 tasks
ericwa opened this issue Jan 28, 2016 · 2 comments
Open
3 tasks

Drop/deprecate broken or unused features #43

ericwa opened this issue Jan 28, 2016 · 2 comments
Labels

Comments

@ericwa
Copy link
Member

ericwa commented Jan 28, 2016

  • drop support for storing persistent properties outside of variable storage (we talked about this, I think?)
  • remove serialization accessor support and -isCoreObjectValue: hack once EtoileUI uses serialization transformers everywhere
  • remove dynamic type hack (based on NSObject) in serialization once EtoileUI supports persisting references to "arbitrary" model objects in a better way (see ETLayoutItem.representedObject)

That's all I can think of at the moment

@qmathe
Copy link
Member

qmathe commented Jan 28, 2016

It's not really possible to drop support for storing persistent properties outside of the variable storage (at least for attribute properties). If you write 2D or 3D applications, accessing the geometry state is one of the most common operation and must be very fast. For example, in EtoileUI 'position' and 'size' are accessed through the ivars, since using accessors slows things a lot for drawing or hit tests.

I think migrating all persistent multivalued properties to COArray/Set/Dictionary was the most important thing to reduce COObject complexity and support relationships properly (e.g. hidden dead refs, cross persistent roots). CODictionary remains to be written though.

We should probably restrict ivars support to attributes, this would eliminate the trouble to deal with hidden dead ref or lazy loading for univalued relationship backed by ivar.

If we do this, it's then easy to eliminate all the overhead/complexity associated with ivars support. The code to support ivars could be reduced to only 10 lines.

@qmathe
Copy link
Member

qmathe commented Jan 28, 2016

I updated your initial list a bit. I'll add any other thing I can think of.

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