At Wed, 28 Jan 2015 16:21:51 -0700, Byron Davies wrote:
> Your code, commented:
> (define orig-i (current-inspector)) ; saves the original inspector
> (define sub-i (make-inspector orig-i)) ;make a new inspector whose parent
> is the original inspector
> (current-inspector sub-i) ;makes the new inspector the current inspector
> (struct a (x)) ; creates a structure using the new inspector as the
> default inspector
> (define v (a 1)) ; creates an instance of the new structure
> (current-inspector orig-i) ;reverts the inspector to the original (the
> parent of the new inspector)
> I see how this works, but I'm a little confused about why it works. I see
> that the new inspector is a child of the old one, and I read in the
> reference chapter that access is determined not by the inspector in force
> at creation time, but by the parent of that inspector, i.e., the old
> inspector. I can't find any description of the "power" of an inspector,
> except that the parent is more powerful.
> Are there degrees of power? Or if you have access to the parent do you have
> all the power you can have?
There are degrees only in that you can have a hierarchy of inspectors.
Inspector I is more powerful than inspector J if I is an ancestor of J.
I'll try to improve the docs, such as replacing "more powerful than"
with "an ancestor of".
> I see that the inspector gives you access to
> the data in a structure instance, but does it also give you access to
> meta-data, so that I know that the name of the first field in struct a is x?
You get access to all the metadata.
It turns out that fields currently have only positions, not names, but
that choice was not a good one. We plan to add support for field names
in the near future, in which case the information will be accessible
through an inspector.
> I also don't understand how the root inspector works. I have found that
> setting (current-inspector root-inspector) delivers endless left parens for
> the (a 1) example, presumably because the display function recursively
> tries to inspect the components of the struct, all the way down.
That's a problem in the pretty printer. The pretty printer's
[(struct? v) ....]
[(unquoted? v) ....]
where `unquoted` is an internal structure. By setting the inspector to
the root inspector, a value that satisfies `unquoted?` also satisfies
`struct?`, and so printing doesn't reach the intended case. I'll push a
> Finally, does this also work for classes?
Yes. Reflective access to information via `object-info` and
`class-info` is controlled by inspectors.
Racket Developers list: