> > Thank you for the explanation. Can I ask why the heck it works this > way? This seems to be explicitly designed for maximal surprise and > minimal usefulness. >
It works that way so that, by default, modules can't inspect, modify, or otherwise muck around with structs defined by other modules. Opaque structs (that is, structs that aren't transparent and aren't prefab) aren't really meant to be used like "plain old data objects" with fields and accessors, they're more like building blocks for abstract data types. A module that defines an opaque struct type is expected to be responsible for exporting to other modules all the functions that are necessary for using that type. Anything not explicitly exported by the module is not allowed, even through reflective operations like struct-info. The exception to this rule is when some entity *above* the modules is controlling them all, such as a debugger, an IDE, or a server running client-supplied code. In these cases, the controlling code has the option to make a child inspector and run all the modules under that child inspector, giving the controlling code access to all struct types through the parent inspector. This kind of setup can be nested arbitrarily deep. This is nice for defining abstract types, but it can be pretty inconvenient for defining plain old aggregated data types that just have a bundle of fields. When defining those types as structs, consider using the #:transparent option. This means "use no inspector at all" (roughly) and lets `struct-info` Just Work (TM) without any inspector wrangling. The downside is that other modules may be able to break your type's invariants and possibly circumvent your contracts. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
