After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 610574 - [jsapi-util] Add a few convenience macros
[jsapi-util] Add a few convenience macros
Status: RESOLVED FIXED
Product: gjs
Classification: Bindings
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gjs-maint
gjs-maint
Depends on:
Blocks: 610370
 
 
Reported: 2010-02-21 02:50 UTC by Johan (not receiving bugmail) Dahlin
Modified: 2010-02-24 22:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[jsapi-util] Add a few convenience macros (4.15 KB, patch)
2010-02-21 02:50 UTC, Johan (not receiving bugmail) Dahlin
none Details | Review
[jsapi-util] Add a few convenience macros (4.31 KB, patch)
2010-02-22 17:04 UTC, Johan (not receiving bugmail) Dahlin
accepted-commit_now Details | Review

Description Johan (not receiving bugmail) Dahlin 2010-02-21 02:50:33 UTC
This are required by the cairo bindings, in which it will be necessary
to use macros as the module will create various prototypes. (10+)
Comment 1 Johan (not receiving bugmail) Dahlin 2010-02-21 02:50:36 UTC
Created attachment 154297 [details] [review]
[jsapi-util] Add a few convenience macros

GJS_DEFINE_PROTO/GJS_DEFINE_PROTO_ABSTRACT are boilerplate macros
which significantly reduces the amount of code required to create a new prototype.
Comment 2 Johan (not receiving bugmail) Dahlin 2010-02-22 17:04:35 UTC
Created attachment 154415 [details] [review]
[jsapi-util] Add a few convenience macros

GJS_DEFINE_PROTO/GJS_DEFINE_PROTO_ABSTRACT are boilerplate macros
which significantly reduces the amount of code required to create a new prototype.
Comment 3 Colin Walters 2010-02-24 14:55:38 UTC
Review of attachment 154415 [details] [review]:

With the huge caveat that I'm not all that familiar with this part of the Spidermonkey APIs, this patch looks basically reasonable.  I notice though there are a lot of flags we're hardcoding here, and it's unclear to me how often/when we might want those to vary.  With this we're basically saying there's one "right" way to define a JSClass for objects representing C types, right?
Comment 4 Johan (not receiving bugmail) Dahlin 2010-02-24 14:59:23 UTC
Well, these macros have worked out pretty well for me & the cairo use case. Which is 3 abstract and 8 non-abstract (so-far) classes. We might want to add other macros which allows you to specify the FLAGS and/or modify the parameters send to JS_InitClass, but in most cases we just don't care, we just want a simple prototype that can be instantiated and has some methods.

Havoc, what do you say?
Comment 5 Havoc Pennington 2010-02-24 21:20:53 UTC
Review of attachment 154415 [details] [review]:

It seems a bit like the macros only handle one particular case. But doesn't seem worse than the rest of the gjs "internal" API :-P
if it fixes cairo cut-and-paste why not experiment with it and maybe we can extend it to more cases over time.
Comment 6 Johan (not receiving bugmail) Dahlin 2010-02-24 22:46:34 UTC
Fixed in HEAD, thanks!