JADE Environment Development Ideas

This has been raised previously (PAR #64786), which has been under investigation for some time now. Copying here so it's more visible to others, as it complements #187.

Packages would be more powerful if imported classes inherited from the ancestor which is most common to both schemas.

During recent development, we?ve attempted to export and use classes which reuse framework functionality from a common super-schema. However, because the imported class doesn?t inherit from the relevant super-class in the framework schema, and duplicating the framework by re-importing things confuses matters .. we cannot use/supply instances of the imported classes to other framework functions inherited directly, due to compile time issues with errors indicating the class isn?t the right type, or doesn?t have a method/property.

For the recent development, we?ve ended up having to fall-back to older ?peer schema? approaches, where we create objects in the importing schema without actually importing the class .. and then we?re able to typecast/supply it to framework functions. However, if we happened to export/import the class via the package again, this approach would break because it?s then treated as inheriting from the most relevant RootSchema class (Object in this case, but we?ve also experimented with custom table controls, which inherits from another table abstraction in our base schema).

From an overall system design perspective, this ability would be advantageous in situations where other JADE developers want to build a new system in a modular fashion. This would allow developers to define base components/abstractions in a base/core framework schema, which is then inherited by modules defined in sub-schemas. These could then interact with each other using packages. At runtime, we then have a system which can still work in an integrated manner, but also a dynamic/decoupled manner where the combination of schemas could ultimately vary for each installation. This may also provide additional options/flexibility for JADE developers who need to customise functionality for individual clients/sites, where whole schemas/modules could be swapped for customised versions, while still retaining the ability to reuse/leverage a core/base set of functionality which is maintained/defined in one place.