Hey Paul, This seems like an abuse of POD to me. Disadvantages include:
1. Someone can upload junk modules that force yours to link to it (this may not be a problem if users are clear that mention of a module in perldoc is not an endorsement); and 2. There's no support for this behaviour in perldoc or other tools; and 3. You have a similar problem if you develop a module that can optionally be used with other modules. Granted, this seems much less common than your proposed use case. It seems more appropriate to allow module authors to annotate their MetaCPAN module pages somehow, but then you run the risk of the annotations becoming stale compared to the code, or having to manually re-do the annotations each time you upgrade, or something like that. Are there any insights that can be gleaned from AnnoCPAN? Considering your specific use case, I also wonder if something like javadoc's "direct known subclasses" annotation is possible (it seems this may not be solvable in general due to the way Perl OO works, but maybe there are patterns such that we can develop a "good enough" heuristic.) An alternative (which can be done today) is to just link to a MetaCPAN search covering that namespace; in your example, just to search for everything under Tickit::Widget. Cheers, Jonathan On Tue, Mar 31, 2015 at 12:29 PM, Paul "LeoNerd" Evans < leon...@leonerd.org.uk> wrote: > Random musings from #perl on Freenode: > > If I write a base module that's intended for expansion/extension (such > as Tickit), and then write lots and lots of extensions (see: the entire > Tickit::Widget:: namespace), it would be nice as an end-user feature > browsing module documentation, to be able to see a list of all those > widgets when looking at the base. Sometimes module developers use a > > =head1 SEE ALSO > > However, for developers that's a terrible solution. It means the author > of the base has to list all the extensions, which will naturally grow > over time. As the base becomes more stable, it increasingly means the > base does "documentation-only" releases that just add to that list. > Also it's hard for third-parties to add it there. > > I wonder if therefore, metacpan needs some sort of back-reference > ability? That if an extension module could somehow list > > =head1 SEEN ALSO BY > > L<Tickit> > > then such a module declaring that would *automatically* get listed > somehow in some automatically-generated and (near)-realtime updated > part of the Tickit documentation when viewed via metacpan. > > Does this sound like something that might gain traction? > > -- > Paul "LeoNerd" Evans > > leon...@leonerd.org.uk > http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS >
