Open Bug 1128299 Opened 9 years ago Updated 2 years ago

Allow specifying a prototype when creating a StructType in Typed Objects API

Categories

(Core :: JavaScript Engine, defect)

x86_64
Windows 8.1
defect

Tracking

()

People

(Reporter: kael, Unassigned)

References

Details

(Keywords: dev-doc-needed, Whiteboard: [DocArea=JS])

The Typed Objects API currently allows you to define new types with 'new StructType({ fields... })'. However, the resulting type has a .prototype of a specific type (TypedProto, I believe), which means you can't simply replace it with one of your own devising. This means that in practice, non-StructType prototypes can't be on a StructType's prototype chain. Worse still, without .extend() this means you can't insert things into a StructType's prototype chain at all unless you fiddle with Object.

From my discussions with Luke, my proposal is as follows:

Under normal circumstances, a created StructType instance st has Object.getPrototypeOf(st.prototype) === TypedProto.prototype.

StructType's constructor accepts a second optional argument, a dictionary. I believe transparency/opacity already requires this.

The optional argument can contain:
{ prototype: userProto }

If provided, this causes userProto to replace TypedProto.prototype in the prototype chain:

Object.getPrototypeOf(st.prototype) === userProto

This means an end-user can insert one or more layers in the middle so that common functions and properties can be shared between structured types. This would be extremely useful for JSIL, without it I will pay a significant performance penalty.

I think in general the alternative to this would be people creating 0-byte structured types to act as 'base classes' to hang functions/properties off of, which is gross.

One unclear issue: What happens if the prototype doesn't have TypedProto.prototype on its prototype chain? Will things break? I would hope that all essential properties and functions are set directly on st.prototype instead of being inherited.
Keywords: dev-doc-needed
Whiteboard: [DocArea=JS]
Indeed this limitation of a StructType... being limited to acting as a struct, can hinder some code. I tried using StructType as a way to enforce typing on some properties, but alas, I was only able to use it for storing data on sprite attributes: https://github.com/grantgalitz/IodineGBA/blob/master/IodineGBA/IodineGBA/graphics/GameBoyAdvanceOBJRendererCore.js#L106

I guess the general desire of people using StructType at first glance is to use it for being regular objects with types enforced on properties, rather than as the intended c struct use case.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.