Hans-Christoph Steiner wrote: ...
If we have the core objects directly in the standard path (../extra),
then we can have the various additions in subfolders of that path. As
long as the objects are compiled as individual files, they can be
instantiated separately. A while back, I posted an example of this
yes, it is a good start, certainly better than having no structure at all...
Guenter's model has two parts. One part is that any non-standard object name is to be qualified by the relative path to its class' library. Second part is that any library may provide only a single class.
These two parts are unrelated. If the first part, using GG's qualifiers, was widely adopted, then multi-class libraries would just be expected to pass qualified names to class_new(), or class_new() itself would be easily modified to impose that.
I think it is time to stop arguing for and against multi-class libraries, because the actual challenge is in designing a good model for the context in which a patch loads and operates, maintaining a consistent behaviour in different environments and through a long time.
Krzysztof
PS. GG's qualifiers are a good start, but they are not going to work, unless one of the following happens:
. the set of predefined externals is always empty . all predefined externals are loaded at startup . class_new() is changed, so that [another/class] does not declare [class]
Besides, all externs using class_setsavefn() would have to be revised.
PPS. Explicit use of GG's qualifiers is ugly and takes too much space. Some kind of abstraction-scoped "import" mechanism would be necessary, anyway ([declare]?).