create new tag
, view all tags

Feature Proposal: Don't Ship *.pm Documentation Topics


Discourage use of undocumented functions.

Description and Documentation

As of TWiki 4.1, TWiki ships with 55 *.pm documentation topics, from TWikiAccessControlExceptionDotPm through TWikiUsersTWikiUserMappingDotPm. This looks like an invitation for casual users to use internal TWiki functions. For example, see WhereFindNoticeOfApiChanges.

On the other hand, developers are encouraged to use an SVN checkout to work on TWiki and TWiki extensions. Even though more useful for developers, the SVN checkout does not have the *.pm documentation topics.


  • Remove all *.pm documentation topics from the distribution except the ones we officially promote, namely

Open question:

  • Can we do anything to make *.pm documentation more accessible to core developers?


WhatDoesItAffect: Documentation

-- Contributors: PeterThoeny - 20 May 2007


yes, i agree that we shouldn't ship those files.

more accessible to core developers? if they want to see that doc within twiki, then they can install PerlDocPlugin or use perldoc TWiki::Module

-- WillNorris - 20 May 2007

I agree. We need to document the exceptions (TWiki::OopsException and TWiki::AccessControlException) and TWiki::Attrs (utility class) as well.

As for making the pm doc more accessible to developers, can't we use the PerlDocPlugin? I thought that was what it was for....

Arguably we need to add

  • TWiki::InfixParser
  • TWiki::ListIterator
  • TWiki::LineIterator
  • TWiki::Time
as these are all stable classes that provide services likely to be useful to plugins authors.

-- CrawfordCurrie - 20 May 2007

To make it really clear what is official API, would it make sense to rename TWiki::OopsException to TWiki::Func::OopsException? (same with all other official modules.)

-- PeterThoeny - 20 May 2007

Hmmm. That's a tough one. While I agree with the principle of grouping public packages, 'Func' has a loaded meaning to me; it means "here's a functional API that you can use if you can't get your head round object orientation". As such naming objects into that package hierarchy is just confusing.

A better approach would be to use a more intention-revealing name; for example TWiki::Public. Shame Func missed the boat, it would have been TWiki::Public::Func.

However I suspect we are too late for any of these renames. OopsException and AccessControlException are already being used by some extensions. it would be easier to rename the Core classes to distinguish them from the public interface e.g.


-- CrawfordCurrie - 21 May 2007

As for making the docs more available to developers, developers can use tools/gendocs.pl to create the doc topics and put them in the TWiki web.

+1 to the renaming of the Core modules.

-- RafaelAlvarez - 21 May 2007

It is definitely too late to rename TWiki::Func.

To remain compatible, is there a way to have one and the same module exposed as TWiki::OopsException and TWiki::Public::OopsException?

-- PeterThoeny - 21 May 2007

Will says there is; but I think it's the wrong way to go. i would far rather rename the unpublished modules, and leave the published ones (such as TWiki::Func and TWiki::OopsException) untouched.

-- CrawfordCurrie - 21 May 2007

It looks like we have an agreement to not ship TWiki's internal Perl module docs with the TWiki package. I filed Bugs:Item4177 to track this item.

-- PeterThoeny - 01 Jun 2007

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2007-06-01 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.