Jsctypes/api: Difference between revisions

Jump to navigation Jump to search

Jsctypes/api (view source)

Revision as of 20:12, 16 October 2009

1,424 bytes removed ,  16 October 2009
→‎Implementation notes: resolved as suggested
(long and unsigned long autoconvert to Int64/UInt64, not number.)
(→‎Implementation notes: resolved as suggested)
Line 663: Line 663:


* With 2), we will have different CType proto objects per ctypes instance. Will this be an issue for code wanting to pass ctypes objects between module instances? ctypes does not internally depend on prototype object equality, only on JSClass equality, so it will work. Consumers will have trouble if they want to compare prototype objects, however. I'm not sure if this is a big deal. Also, doing this means that we need to stash the CType proto object somewhere, so it's accessible from C++. I don't think we can depend on having the 'ctypes' object hanging off the global object - unless we make it readonly - in which case we need to have the CType proto object hanging off each object we create. (Which we should get for free, as long as all the type object __proto__'s are readonly!) So, either we make the 'ctypes' property readonly, or we make {every type object}.__proto__ readonly, or both.
* With 2), we will have different CType proto objects per ctypes instance. Will this be an issue for code wanting to pass ctypes objects between module instances? ctypes does not internally depend on prototype object equality, only on JSClass equality, so it will work. Consumers will have trouble if they want to compare prototype objects, however. I'm not sure if this is a big deal. Also, doing this means that we need to stash the CType proto object somewhere, so it's accessible from C++. I don't think we can depend on having the 'ctypes' object hanging off the global object - unless we make it readonly - in which case we need to have the CType proto object hanging off each object we create. (Which we should get for free, as long as all the type object __proto__'s are readonly!) So, either we make the 'ctypes' property readonly, or we make {every type object}.__proto__ readonly, or both.
'''Arrays as function arguments.''' When declaring arrays as part of a struct, union, or another array in C, the data is inline. When passing as a function argument, however, they are passed by pointer. Further, C allows implicit type conversion from array to pointer (for the topmost array level). You can't have an array return type in C. Thus we have two options.
* 1) Forbid function declarations with arrays as parameter types. What you really mean by <code>void foo(char c[8]);</code> is <code>void foo(char* c);</code>, so the ctypes declaration could look like <code>const foo = ctypes.declare(..., ctypes.char.array(8).ptr);</code> and at call time you would pass the array by <code>array.address()</code>. (If you actually want to pass an array by value, stick it in a struct first, just like in C.)
* 2) Have things magically convert. There are two parts to this.
** a) <code>library.declare</code>, when given an ArrayType, automatically does <code>.ptr</code> for you.
** b) <code>ImplicitConvert(val, t)</code> will deal, in the general case. If val is a CData object of ArrayType u, and t is a PointerType whose baseType is an ArrayType v, and <code>SameType(u, v)</code> is true, then return a pointer to the array.
* 3) As above, but have <code>ImplicitConvert</code> only do array -> pointer conversion when converting a parameter for a function call.
:I like 2), because it's most consistent with C.
Jorend
638

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/176236"

Navigation menu