unique ids, arrays or maps?

[immersive-web]

unique ids, arrays or maps?

[bialpio]

Is there anything preventing you to store plane objects into a map now? Plane objects don’t carry an ID, but there is no reason why the application couldn’t add it:

let map = …;  // map to store the planes
let plane = …;   // plane obtained from some xrFrame.worldInformation

plane.id = getNextId(); // function that creates UUID or something
map.set(plane.id, plane);

This is possible because we guarantee that plane in frame N is represented by the same plane object in frame N+1, so the application won’t lose additional properties that it added to plane objects.

[blairmacintyre]

Unpacking a bit.

Plane objects don't carry an ID

Do you mean ARCore plane objects, or the design you posted here? Your design proposal is just that, a proposal, so plane objects could carry an id; the point of my post was to suggest that. Why would we force every app to include code like that if they don't need to, if it's obviously useful?

This is possible because we guarantee that plane in frame N is represented by the same plane object in frame N+1, so the application won’t lose additional properties that it added to plane objects.

I don't recall seeing this in the proposal, and it seems like a pretty significant guarantee. It may very well be that we want to make that guarantee, but it's not obvious we do.

Is it typically the case that objects returned from native APIs have such a guarantee, and that these objects can have data added to them?

[bialpio]

Do you mean ARCore plane objects, or the design you posted here?

Both (ARCore does not expose plane ID, although the address it returns is unique).

Why would we force every app to include code like that if they don't need to, if it's obviously useful?

My understanding is that it is not really useful due to the guarantee about maintaining the identity of the plane objects. Exposing IDs might be useful to introduce a way to decorate plane objects with additional data (by inserting the additional data to a map keyed with plane ID), but this is not needed if we just allow attaching objects to them (ex. plane.context = {... object with everything you might want to store with a plane ...}. I don’t really see another use for an ID, but I might be missing something here. Added benefit is that the application does not need to maintain the “plane ID to something” map.

Is it typically the case that objects returned from native APIs have such a guarantee, and that these objects can have data added to them?

I don’t think JavaScript cares about where the object came from, apps can add properties to it at runtime. As for other examples that already give this guarantee, anything that is annotated as [SameObject] has that guarantee - one example is XRSession’s renderState (https://immersive-web.github.io/webxr/#xrsession-interface).

[bialpio]

Closing stale issue - I'm leaning towards omitting placing IDs since the objects we're returning can be updated in place (so triple-equals comparison will work when checking if object we got in rAF1 is the same as the one in rAF2).