The base level for a library class should have a defined minimum of attributes and methods defined within it. Here are some I am thinking of:
class xoopspoll
{
const VERSION = '1.2.3';
const RELEASE_DATE = '02/12/2013';
const AUTHOR='Rodney Fulk';
const AUTHOR_EMAIL='nospam@here.com';
protected $mod;
public function __construct($mod, site = '')
{
$this.mod = $mod;
}
}
May have to make additions to this but the basic idea is the following.
The release date should be the release date of this version.
The author and email is of the official author of the official version.
The name of the module is passed to the constructor so that it can access the proper database. (Note this will allow for cloned modules to use the same code...)
This module name would be of the module you want to access the information for so it could be the name of the module running or another module. For xoopspoll you would call the class with the name xoopspoll.
In this case if you were using CBB and it was making use of the xoopspoll class so it could interface into the polls you would include the CBB class with the module name being CBB and you would also include the xoopspoll class with the module name of course being xoopspoll.
The optional site argument would be for potential multi site support.
The versioning portion is the touchy part of this class. There are 3 different portions to this version. The first portion would be the major portion. All classes of the same major portion would need to be compatible. So any future versions need to be backwards compatible throughout the series so that if you have a program using version 1.0 of a class it will still work with version 1.999 of the class as well. You would only go to 2.0 if the new version contains new functionality. Going from 1 to 2 would still be backwards compatible to the last version of the 1 branch but any replaced methods would be depreciated to be removed in a major version 3.
The mid portion would be the official step increases. They may add some functionality but none can be taken away and should be backward compatible.
The final portion would be the minor portion and would be the maintenance versions. Any minor adjustments or non official additions would be made in these versions.
The first two portions of the version could only be done by the official writer. To release an official newer version the original author would need to make the additions and release the official new version. If the class has not been updated for more than 6 months or permission is given by the original author then someone else can release an "official" version. (Official modules can only be released by the core developers regardless.)
If someone does not want to abide by the rules they can produce their own work but it must be a different name and the class must be a different name. It can be an extension of the official class if so desired as one way to get around this.
Hopefully this won't be much of an issue.