On Tue, Feb 12, 2019 at 4:46 PM <[email protected]> wrote: >> >> 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.
I see. That makes sense. I think it would be worth expanding the documentation on that; I'm happy to provide a suggestion later tonight, but I will need to do it through email instead of via pull request. I have long since given up on being able to find anything in the Racket github in order to provide patches. It's simply too unintuitive and time-intensive to find the relevant section in multiple repositories where the documentation is in randomly-named fragments scattered across multiple directories instead of being individual files with guessable names. > > 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. That's what I expected, but it doesn't seem to work: > (struct person (name age) #:transparent) > (struct-info person) #f #t What am I missing? -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
