Closed
Bug 717886
Opened 13 years ago
Closed 13 years ago
Extend ctypes to permit better interaction with JSAPI from C code.
Categories
(Core :: js-ctypes, enhancement)
Core
js-ctypes
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: Yoric, Unassigned)
Details
JS-ctypes is very convenient to call "pure" C code from JavaScript, but that C code cannot perform advanced interactions with JavaScript, such as publishing objects with custom classes or private slots, due to two limitations:
- the C code does not have access to the JSContext;
- the C code cannot take as argument or return a JSObject.
Experience with the ongoing (re)implementation of OS.File indicates that such features could be quite useful.
Note: This looks dual to bug 592035, but the same patch could possibly solve both issues.
I am willing to mark this as a mentored bug.
Updated•13 years ago
|
Assignee: general → nobody
Component: JavaScript Engine → js-ctypes
QA Contact: general → js-ctypes
Comment 1•13 years ago
|
||
I am somewhat-to-very opposed to the premise of this bug. Coding against the JSAPI is not simple to begin with, and coding against the JSAPI in Javascript sounds like an engineering disaster, both for us and for the extension which will undoubtedly misuse the feature. To the extent that the OS.File implementation cannot implement its classes in JavaScript, I think we should just implement it in JSAPI, and not try to force ctypes into a role which is actively harmful.
Reporter | ||
Comment 2•13 years ago
|
||
Well, the latest version of OS.File privately reimplements a non-negligible subset of js-ctypes just for the purpose of passing arguments from JS to C++. This is rather wasteful, but I do not see any way to escape this unless such code is built into js-ctypes – short of rewriting all the serialization code for every function, which multiplies code size by about 10.
Comment 3•13 years ago
|
||
(In reply to David Rajchenbach Teller [:Yoric] from comment #2)
> Well, the latest version of OS.File privately reimplements a non-negligible
> subset of js-ctypes just for the purpose of passing arguments from JS to
> C++. This is rather wasteful, but I do not see any way to escape this unless
> such code is built into js-ctypes – short of rewriting all the serialization
> code for every function, which multiplies code size by about 10.
Are you talking about ImplicitConvert and friends? We could probably expose that stuff somehow via jsfriendapi...
Comment 4•13 years ago
|
||
Seems like if there are bits of ctypes that would be useful for you, writing raw JSAPI, then we should just make those reusable, no?
Reporter | ||
Comment 5•13 years ago
|
||
Ok, after input from Taras, I have basically reimplemented os.file purely on js-ctypes and extended js-ctypes to permit finalization (see bug 720771). So I do not require the feature covered by this bug anymore.
I am closing that bug. If someone wants to reopen it, feel free to.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•