Re: =head1 SEEN ALSO BY
On 04/04/2015 10:43 AM, Aristotle Pagaltzis wrote: Hi Tim, * Tim Bunce tim.bu...@pobox.com [2015-04-04 13:25]: Independently of that, I'd love to see something like a 'mentioned by' page. It would list all other distros that mention (via an LFoo link) a module in this distro. d’oh – of course. It would look like the revese dependencies page. Or more to the point, “what links here” as seen in many wikis. Bonus points for also recording and showing the header of the pod section that the L was seen in. That was the first thought that popped into my head after the d’oh, too. :-) I like! Now someone’s just gotta do it… I'm not volunteering to do this, but ... it does sound like the sort of thing that would benefit from some attention at the upcoming New York City Perl Hackathon. If someone were to write up a specification, it could be posted on our Projects page: https://github.com/nyperlmongers/nyperlhackathon2015/wiki/Projects Thank you very much. Jim Keenan
Re: =head1 SEEN ALSO BY
On Tue, Mar 31, 2015 at 6: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 LTickit 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? AFAIK there are ways to sneak in a piece of HTML into the POD, so I guess you could XSS yourself ;-) Leon
Re: =head1 SEEN ALSO BY
My 2-cents: I've often wanted to be able to browse the module namespace hirearchy. That would be a great addition. I imagine the UI might be tricky to do well though. Independently of that, I'd love to see something like a 'mentioned by' page. It would list all other distros that mention (via an LFoo link) a module in this distro. It would look like the revese dependencies page. I imagine the implementation would be reasonably straightforward. No need to mess with the presentation of POD. Bonus points for also recording and showing the header of the pod section that the L was seen in. Tim.
Re: =head1 SEEN ALSO BY
Hi Tim, * Tim Bunce tim.bu...@pobox.com [2015-04-04 13:25]: Independently of that, I'd love to see something like a 'mentioned by' page. It would list all other distros that mention (via an LFoo link) a module in this distro. d’oh – of course. It would look like the revese dependencies page. Or more to the point, “what links here” as seen in many wikis. Bonus points for also recording and showing the header of the pod section that the L was seen in. That was the first thought that popped into my head after the d’oh, too. :-) I like! Now someone’s just gotta do it… Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: =head1 SEEN ALSO BY
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 LTickit 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
=head1 SEEN ALSO BY
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 LTickit 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 pgpNfE5DPPYdc.pgp Description: OpenPGP digital signature
