On Tue, Feb 12, 2019 at 3:55 PM David Storrs <[email protected]> wrote: > > 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? >
It takes an instance of person. (struct-info (person "Me" 3.14)) FWIW if you already have the struct type descriptor (which is what struct-info returns), you can directly call struct-type-info. (struct-type-info (let-values ([(desc skip?) (struct-info (person "Me" 3.14))]) desc)) ;; struct:person is introduced by the (struct person ...) form (struct-type-info struct:person) > -- > 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. -- 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.
