[PEAK] Requirements for workspace/schema class generation
Phillip J. Eby
pje at telecommunity.com
Sat Jul 31 01:46:44 EDT 2004
* Schema components must be composable; i.e. it should be possible to list
an arbitrary number of schema components as plugins for a workspace
* Schema components may add behavior to any mutable model class or to any
of its features
* Schema components may specify nested calling exclusions for behavior
additions. That is, if a schema component wishes to modify the behavior of
method M1 of class C, it may specify that this modification should not
occur if M1 was called from the body of methods M2, or M3. This is so that
if M1 is a low-level operation called from higher-level operations M2 and
M3, the aspect may specify a higher-level change to those methods, while
ignoring those methods' internal use of M1.
* Schema components will probably need some place to put components that
their behavior additions will use. (E.g. database connections, state
information, etc.) Some of this might be able to be handled using
closures, but if not we may have to find some place to stick stuff on the
* Generated classes should not vary from the original class' semantics,
except for the modifications requested by schema components, and certain
unavoidable differences (such as the fact that they are not the same object
as the original class!).
* Methods of an original class that use 'super(ThisClass,...)' should
continue to function correctly.
* Explicit construction of other classes in the original class' methods are
allowed to break, because it's evil and deserves to break. ;) That is, no
code in a domain model should create another domain object except via some
intermediary such as 'self.someFeature.typeObject', or a class-level binding.
* In the event the above rule turns out to be too harsh, we *may* implement
a normalization feature such that an orphaned object (one created from a
pure model class) to be "adopted" by a workspace, and maybe even make it
automatic for objects referenced by an object already in the
workspace. But until then, YAGNI.
* Ideally, classes would only be generated once per schema+model
combination. In practice, this probably isn't possible because the classes
*have* to be connected to the workspace for the overall approach to
work. (Well, unless we use 'ws.Invoice(ws)' to create instances, which I
suppose could be worse. Even so, we then run into the "need someplace to
put schema components' data on the workspace" problem even more.)
More information about the PEAK