[PEAK] Requirements for workspace/schema class generation

[Phillip J. Eby]

Schema Components
-----------------

* 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 
workspace.


Class Generation
----------------

* 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.)