On Tue, Feb 12, 2019 at 3:55 PM David Storrs <david.sto...@gmail.com> wrote: > > On Tue, Feb 12, 2019 at 4:46 PM <jackhfi...@gmail.com> 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 racket-users+unsubscr...@googlegroups.com. > 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
