Opened 6 years ago

Closed 4 years ago

#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.

Change History (4)

comment:1 Changed 4 years ago by kzar

  • Owner set to kzar
  • Platform set to Unknown / Cross platform
  • Tester set to Unknown

comment:2 Changed 4 years ago by kzar

  • Owner kzar deleted

comment:3 Changed 4 years ago by fhd

  • Priority changed from P2 to P5

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.

comment:4 Changed 4 years ago 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.

Note: See TracTickets for help on using tickets.