Closed Bug 959013 Opened 11 years ago Closed 11 years ago

Add a mechanism to describe the behavior of a standard class with the JSClass, and test-drive it with Date

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: bholley, Assigned: bholley)

References

Details

Attachments

(4 files, 1 obsolete file)

This is one of the major pieces of XrayToJS, as suggested by jorendorff in bug 914970 comment 1.

This is my plan:

(1) Add an optional js::Class member called |specs| (feel free to suggest another name). This will contain:

{
    JSFunctionSpec instanceFunctions,
    JSPropertySpec instanceProperties,
    JSFunctionSpec prototypeFunctions,
    JSPropertySpec prototypeProperties,
    JSFunctionSpec interfaceFunctions,
    JSPropertySpec interfaceProperties
}

The first set of two are defined as |own| props on instances of the class. The second on the prototype, the third on the class object (constructor).

(2) Rejigger the js_InitFooClass machinery such that it calls a common helper routine first, which defines the {prototype,interface}{Properties,Functions} before calling any custom bootstrapping code. We could also hoist the js_InitFooClass pointers directly into the Class while we're at it, though that might be a lot of work.

(3) Rejigger object creation to define the |own| props.

(4) Start hoisting hand-rolled code from js_InitFooClass into the JSClass, and letting the generic machinery take care of it. The entire conversion process if a mammoth task, and will not be limited to this bug.

Thoughts?
Here's a brief prototype of the js::Class changes, so that we can bikeshed the
naming and whatnot before I build too much on top of this. I ended up calling
it js::ClassSpec, and calling the member |spec|.

I considered rolling this into ClassExtension, but decided that it was probably
cleaner to keep it separate. Otherwise, we'd eventually be declaring all the
junk in ClassExtension in every builtin type's Class.
Attachment #8359021 - Flags: feedback?(jwalden+bmo)
Attachment #8359021 - Flags: feedback?(jorendorff)
Depends on: 959012
Depends on: 959334
Comment on attachment 8359021 [details] [diff] [review]
Strawman - Create storage for JS{Property,Function}Specs on js::Class. v1

My approach has evolved a bit. This is obsolete enough that it's probably not worth looking at for now.
Attachment #8359021 - Attachment is obsolete: true
Attachment #8359021 - Flags: feedback?(jwalden+bmo)
Attachment #8359021 - Flags: feedback?(jorendorff)
Depends on: 962449
No longer depends on: 959334
This is green.
Summary: Hang the JS{Property,Function}Spec hooks for built-in class members off the JSClass → Add a mechanism to describe the behavior of a standard class with the JSClass, and test-drive it with Date
No longer depends on: 959012
Attachment #8364727 - Flags: review?(jorendorff) → review?(luke)
Attachment #8364728 - Flags: review?(jorendorff) → review?(luke)
Attachment #8364729 - Flags: review?(jorendorff) → review?(luke)
Attachment #8364730 - Flags: review?(jorendorff) → review?(luke)
Attachment #8364727 - Flags: review?(luke) → review+
Attachment #8364728 - Flags: review?(luke) → review+
Comment on attachment 8364729 [details] [diff] [review]
Part 3 - Add a standardized initialization mechanism based on the ClassSpec. v1

Review of attachment 8364729 [details] [diff] [review]:
-----------------------------------------------------------------

Beautious

::: js/src/vm/GlobalObject.cpp
@@ +457,4 @@
>      ClassInitializerOp init = protoTable[key].init;
> +    if (init == js_InitViaClassSpec)
> +        init = nullptr;
> +    const Class *clasp = ProtoKeyToClass(key);

Could you add a \n before clasp declaration?
Attachment #8364729 - Flags: review?(luke) → review+
Attachment #8364730 - Flags: review?(luke) → review+
Blocks: 975042
No longer blocks: XrayToJS
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: