Menu
I'm writing an open source patch to use a font library, or rather the haskell bindings to a font library in C (FTGL). I'm pointing to the Font type in one of the data structures, which is defined as follows:
type Font = Ptr Font_Opaque
data Font_Opaque
Unfortunately, to fit into the data structure of the library I'm patching, this type needs to be an instance of Data. Ptr already is, but Font_Opaque obviously isn't, so the compiler complains.
As it's an opaque type I'm not sure how to proceed ... how to implement Data Font_Opaque in a more or less sensible way? Is there a sensible way?
432
An opaque data type is a user-defined or built-in data type that is fully encapsulated. The internal structure of an opaque data type is unknown to the database server. Except for user-defined types (UDTs) that are DISTINCT of built-in non-opaque types, UDTs whose source types are built-in types are opaque data types.
In computer science, an opaque data type is a data type whose concrete data structure is not defined in an interface. This enforces information hiding, since its values can only be manipulated by calling subroutines that have access to the missing information.
"Opaque" is defined, in English, as "not able to be seen through; not transparent". In Computer Science, this means a value which reveals no details other then the type of the value itself.
By "opaque" they mean that the inner structure exists, but is unknown. So the program is expected to treat the string as a whole - store it, transmit it, but not try to interpret.
As the comment by András Kovács suggests, using the StandaloneDeriving language extension
{-# LANGUAGE StandaloneDeriving -#}
and then:
deriving instance Data Font_Opaque
did the trick, at least where the compiler is concerned. I'll report back if this affects the program in any way. Thanks!
134
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With