[qmtest] RFE concerning 'Extension' class

[Stefan Seefeld]

Mark Mitchell wrote:

> We actually have a not-insignificant body of test classes out there in
> the wild at this point.  Things like the Database API are a little less
> hard to change, but the basic test class API, including the "arguments"
> variable, are going to be tricky to change.

ok, fair enough. But migrating existing code is only half of the story.
The other half is allowing a more elegant way to deal with arguments
for new code (extensions) to be written.
In other words: the question is not how to continuously support classes
that contain an 'arguments' class variable, but how to make it possible
to avoid such classes in the future.

> I'm actually hoping that we're getting very close to the point of
> completely freezing the API, i.e., of adding new functionality but not
> breaking existing code ever again.  I don't (yet!) see your suggested
> improvement as providing enough leverage to make it worth breaking
> stuff.

What started me thinking about this was the moment I realized that
classes as low level as 'Suite' had become an Extension, and I wondered
how to mitigate the consequences such a decision has (no direct loading
of these classes, non-intuitive API conventions such as the above, etc.)

As Zack points out, there are other interesting things we could do with
metaclasses. For example, using the very same technique I suggest, it
is possible to record all available extensions from their 'type constructor',
meaning even if extensions would be layed out as ordinary modules, it's
still possible to locate them and list all available extensions of a given
'kind', meaning you *can* have both, direct loading via import of an
extension class *and* all the metadata stuff you want (querying of data
about available extensions, serialization, etc.)

Regards,
		Stefan