Opened on 04/04/2014 at 10:11:00 AM
Closed on 02/04/2016 at 10:57:07 AM
#259 closed change (rejected)
[Typed objects] Implement forward declarations for types
Reported by: | trev | Assignee: | |
---|---|---|---|
Priority: | P5 | Milestone: | |
Module: | Core | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | #145 | Platform: | Unknown / Cross platform |
Ready: | yes | Confidential: | no |
Tester: | Unknown | Verified working: | no |
Review URL(s): |
Description
Background
See #145. The ECMAScript Harmony proposal doesn't define any forward declaration mechanisms. Consequently it is impossible to have a property that references another object of the same type. Cyclic references aren't possible as well (Type1.foo has type Type2, Type2.bar has type Type1). We need this functionality however.
What to change
Some API like the following can work:
let FutureType = new ObjectType.FutureType(); let Type = new ObjectType({ foo: FutureType }, {type: FutureType});
This should reserve a type ID in the FutureType object. It can then used in reference declaration even though the corresponding type isn't defined yet. Then at some point a type is created with type: FutureType parameter which means that the reserved type ID should be used for it.
Attachments (0)
Change History (4)
comment:1 Changed on 08/18/2015 at 12:06:06 PM by kzar
- Owner set to kzar
- Platform set to Unknown / Cross platform
- Tester set to Unknown
comment:2 Changed on 10/22/2015 at 08:05:34 PM by kzar
- Owner kzar deleted
comment:3 Changed on 02/04/2016 at 07:55:37 AM by fhd
- Priority changed from P2 to P5
comment:4 Changed on 02/04/2016 at 10:57:07 AM by trev
- Resolution set to rejected
- Status changed from new to closed
In fact, at that point I am certain that we are dropping typed objects and go with Emscripten instead. The performance issues we had with Emscripten initially are bound to affect us with typed objects as well (important points: static generation of JS bindings, stack-based allocations, likely more). Fixing these issues was already non-trivial with Emscripten, but with our own toolchain it will require far more effort - this isn't going to pay off if we have a reasonable and maintained alternative.
Since the Emscripten based approach is looking rather good, I'm not sure we really want to continue to work on Typed Objects. Makes it a P5.