Opaque types
When a native library uses a type in its API without revealing the actual fields and layout of that type (as is the case with structs), the type can be called opaque. Such values cannot be allocated or freed, and can only be used meaningfully by passing them to the methods of the native library that defined them in the first place.
To define an opaque type, extend ammer.def.Opaque<...>
with a Haxe class. The first type parameter for ammer.def.Opaque
should be a string identifying the native C type name. The second type parameter should be the ammer
library this type belongs to.
Although opaque type definitions cannot contain any variable fields, they may still contain instance methods.
Example: opaque type definition
class FoobarOpaque extends ammer.def.Opaque<"opaque_t", Foobar> { // ... }
In this example, FoobarOpaque
is an opaque type of the Foobar
library. The C name for this type is opaque_t
.
Linking
Opaque types should be linked with the parent library using the @:ammer.sub(...)
metadata to avoid compilation errors. See linking subdefinitions.
Metadata applicable to opaque types
Not yet implemented: large opaque types
Currently, ammer
assumes every opaque type is pointer-sized or smaller. This allows passing it between Haxe and native code without any allocations. Supporting opaque types that do not fit into a pointer is a planned feature.