Automatically managed references

[DaanVanYperen]

Code generation, clear expired ID's on components using generated code. Replaces EntityReferences.

• [ ] @EntityId int
• [ ] Entity
• [ ] @EntityId IntBag
• [ ] Bag
• [ ] GWT Support

[DaanVanYperen]

@junkdog what do you think, been bashing my head against EntityReference for a while now.

might be nice and transparent if we manage references for the user, or is this over engineering it? Manually managing references is a pain in the butt.

Thinking of generating something (on @EntityId or @Weave trigger) like

class MyComponent extends PooledComponent implements EntityRemovalObserver {

   public @EntityId int entityA;
   public @EntityId IntBag entitiesB;
   public Entity entityC;
   public Bag<Entity> entitiesD;

   public deleted(IntBag entities) {
           ..
           if ( entityA == id ) entityA = null;     
           ..
   }
}

Pretty sure we if we can weave it the GWT is relatively peanuts.

Hmmm guess performance won't be the best without some subscription going on.

[DaanVanYperen]

Considered alternatives

• EntityReference requires some setup and unwrapping by the user and is impossible to pool, plus clashes a bit with io.
• Considered a EntityVersionManager and a corresponding long or int that holds entityId+version. Again not really intuitive. @mtsr

[DaanVanYperen]

Edit: Without a way to subscribe entities to specific components it would have to cycle all components vs all deleted entities O(n²).

We could add a dirty check before batch delete that builds a map of entities vs referring components? That could make it O(n) for the dirty check and an effective O(n) for actually clearing the references.

Edit: That would cause some dangling references till batch delete, though can't immediately think of a use case where that would be an issue.

We'd be paying an iteration cost on delete for the empty references compared to EntityReference. EntityVersionManager would be technically a lot simpler. Possibly faster. though not as neat and convenient for the user.

[junkdog]

Manually managing references is a pain in the butt.

Hmm, I need to look closer into this, because I've never had a problem with specifically tracking references. Probably because I've never faced the use-case where it's tricky to track.

Early NPE for deleted entities could be solved via the pre-processed debug build, but I guess that won't suffice?

What about something like:

@AutoManagedEntityReferences // verbosity aside...
class MyComponent extends PooledComponent {

   public @EntityId int entityA;
   public @EntityId IntBag entitiesB;
   public Entity entityC;
   public Bag<Entity> entitiesD;
}

Reflection-based removal for normal behavior, auto-managed when weaving. The perf hit is potentially pretty big though. entitiesB and entitiesD should be backed by a bitset for quick lookup, at least.

[junkdog]

@AutoManagedEntityReferences would prob tie into a ReferenceEntityManager or such.

[DaanVanYperen]

Hmm, I need to look closer into this, because I've never had a problem with specifically tracking references. Probably because I've never faced the use-case where it's tricky to track.

We're both very acquainted with the system so that's what I'd expect. ;)

One argument is Artemis is effectively a life-cycle management framework. It black boxes everything about life-cycle management, except for entity references? Ints getting recycled is part of the black box but somehow ends up on the devs plate. So new devs get unexpected fail-slow issues that are hard to trace back to origin

Besides that there's the argument of convenience, cleanup of referencing entities is something you'd ideally do once, centralized and transparently.

Reflection-based removal for normal behavior, auto-managed when weaving

I didn't even consider reflection as feasible. You feel weaving is a bad requirement for dev's if can cover all the platforms? Guess it'd break typical IDE use.

entitiesB and entitiesD should be backed by a bitset for quick lookup, at least.

After sleeping about it a night I feel this is over engineered. Id validation is something odb should intrinsically solve.