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

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

Add Comment

Modify Ticket

Change Properties
Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
 
Note: See TracTickets for help on using tickets.