Library standardization

[Robert Fraser]

Sean Kelly wrote:
> == Quote from Robert Fraser (fraserofthenight at gmail.com)'s article
>> Sean Kelly wrote:
>>> The package attribute seems to cover every instance
>>> where I'd want to expose some special functionality outside a module.
>> But it doesn't work. A package function isn't added to the vtable, so
>> you can't expose a function that says "this function should be used only
>> within this package AND is designed to be overriden (by other classes in
>> the package)".
> 
> Um, what?  Who would ever want to do such a thing?  And why do you
> think it should work?  Static class member functions aren't virtual
> either.
> 
> 
> Sean

Me. I wanted to create a reflection package for flute, where a number of 
cooperating classes provide reflection information. One class is used to 
provide stack traces, which are done in a system-specific manner (that 
is, differently on Windows and Unix) and so the Windows class an the 
Unix class both extend a single abstract base class. Only one of the 
methods in this stack trace provider class should be accessible outside 
the package -- getStackTrace() ("get a stack trace for this executing 
address"). However, a different method, getLineInfo() ("scan the debug 
info for the file/line of this executing address") is used by a 
different function in the package (but not within that module).

In summary:
- There's a set of cooperating modules in a package
- Some of the functionality in a class needs to be exposed only within 
that package
- That functionality is not "static", it relies on member variables
- That functionality relies on virtual dispatch

My solution? Put everything in one huge module and make the functions 
that were going to be package-protected module-private.