638
edits
Jsctypes/api: Difference between revisions
Jump to navigation
Jump to search
tidying up
(→Implementation notes: resolved as suggested) |
(tidying up) |
||
| Line 228: | Line 228: | ||
:''(Open issue: Does this pointer keep ''cdata'' alive? Currently not but we could easily change it. It is impossible to have all pointers keep their referents alive in a totally general way--consider pointers embedded in structs and arrays. But this special case would be pretty easy to hack: put a <code>.contents</code> property on the resulting pointer, referring back to ''cdata''.)'' | :''(Open issue: Does this pointer keep ''cdata'' alive? Currently not but we could easily change it. It is impossible to have all pointers keep their referents alive in a totally general way--consider pointers embedded in structs and arrays. But this special case would be pretty easy to hack: put a <code>.contents</code> property on the resulting pointer, referring back to ''cdata''.)'' | ||
:'''<code>''cdata''.constructor</code>''' - Read-only. The type of ''cdata''. ''(Implementation note: The prototype of ''cdata'' is an object that has a read-only <code>constructor</code> property, as detailed under "minutiae".)'' | :'''<code>''cdata''.constructor</code>''' - Read-only. The type of ''cdata''. ''(This is never <code>void_t</code> or an array type with unspecified length. Implementation note: The prototype of ''cdata'' is an object that has a read-only <code>constructor</code> property, as detailed under "minutiae".)'' | ||
:'''<code>''cdata''.toSource()</code>''' - Return the string "''t''(''arg'')" where ''t'' and ''arg'' are implementation-defined JavaScript expressions (intended to represent the type of <code>''cdata''</code> and its value, respectively). The intent is that <code>eval(''cdata''.toSource())</code> should ideally produce a new <code>CData</code> object containing a copy of ''cdata'', but this can only work if the type of <code>''cdata''</code> happens to be bound to an appropriate name in scope. | :'''<code>''cdata''.toSource()</code>''' - Return the string "''t''(''arg'')" where ''t'' and ''arg'' are implementation-defined JavaScript expressions (intended to represent the type of <code>''cdata''</code> and its value, respectively). The intent is that <code>eval(''cdata''.toSource())</code> should ideally produce a new <code>CData</code> object containing a copy of ''cdata'', but this can only work if the type of <code>''cdata''</code> happens to be bound to an appropriate name in scope. | ||
| Line 267: | Line 267: | ||
:'''<code>''carray''.addressOfElement(''i'')</code>''' - Return a new <code>CData</code> object of the appropriate pointer type (<code>ctypes.PointerType(''carray''.constructor.elementType)</code>) whose value points to element ''i'' of ''carray''. If ''i'' is not a JavaScript number that is a valid index of ''carray'', throw a <code>TypeError</code>. | :'''<code>''carray''.addressOfElement(''i'')</code>''' - Return a new <code>CData</code> object of the appropriate pointer type (<code>ctypes.PointerType(''carray''.constructor.elementType)</code>) whose value points to element ''i'' of ''carray''. If ''i'' is not a JavaScript number that is a valid index of ''carray'', throw a <code>TypeError</code>. | ||
== Aliasing == | == Aliasing == | ||
| Line 654: | Line 650: | ||
=Future directions= | =Future directions= | ||
* | * Callbacks (JITting native wrappers that conform to a given C/C++ function-pointer type and call a JS function. Finding the right cx to use will be tricky.) | ||
* Array slices, a way to get a <code>CData</code> object that acts like a view on a window of an array. E.g. ''carray''.slice(start, stop). Assigning one slice to another would memcpy. | |||
=Implementation notes= | =Implementation notes= | ||
'''The ctypes instance.''' Currently, via ctypes.jsm, we instantiate a fresh ctypes instance each time the module is imported - the global 'ctypes' property will be a different object each time. This doesn't matter right now, because ctypes doesn't have any prototype objects of its own - just object constants and functions. With the API proposal above, it will have a CType object that serves as prototype for the other types. With this in mind, do we want to have 1) a single ctypes instance, which we stash in a C++ static global and hand out on demand; or 2) a separate ctypes instance per import? | '''The ctypes instance.''' Currently, via ctypes.jsm, we instantiate a fresh ctypes instance each time the module is imported - the global 'ctypes' property will be a different object each time. This doesn't matter right now, because ctypes doesn't have any prototype objects of its own - just object constants and functions. With the API proposal above, it will have a CType object that serves as prototype for the other types. With this in mind, do we want to have 1) a single ctypes instance, which we stash in a C++ static global and hand out on demand; or 2) a separate ctypes instance per import? | ||