Jon Lang asked: > Not actually S26; but closely related: should $=POD and .WHY be > read-only?
I had assumed so. > Also, should there be other Pod variables besides $=POD? > If so, which ones? The original idea was that every Pod block with any kind of TYPENAME would be available as $=TYPENAME. For example: $=USAGE, $=OPTIONS, $=SYNOPSIS, etc. In particular, $=DATA is likely to be heavily used. > Back on the subject of S26: should declarator blocks and aliases be > able to introspect the object with which they're associated? That is, > should you be able to say things like A<.WHAT> or A<.^methods>? (If > so, be sure never to say A<.WHY>.) We pretty much have to provide a way for a Pod object to know what Perl object it's associated with. The whole point is to create an open-ended mechanism to allow people to twiddle how Pod is rendered. To do that, they need to be able to walk the documentation tree (a.k.a. $=POD) and extract useful information from any class, code, or variable declarations associated with a particular comment-style node in the doctree. Damian
