Marshall Schor wrote:
Current design has 1 instance of FsClassRegistry per Cas per View.
With the redesign going on for JCas we no longer need one per View.
We don't even need one per Cas. CASes in a pool, sharing the same type
system, can share generators.
Anyone object if I change the impl to move the FSClassReg instance into
the typeSystemImpl instance, since these can be shared by CASes (and I
hope that they are when it's known the CASes are using the same type
system - such as a Cas Pool - if they're not, please let me know).
The FsClassRegistry doesn't really belong in the type system impl. I
would prefer it if we had a new object, e.g., CASMetaData, that holds
both the type system and class registry. This might eventually also
hold the index meta data, if I finally do something about that. A CAS
could then be created from such a meta data object, and the same meta
data can be used for many CASes (like we're now doing with the type
system).
We can still keep a direct pointer to the shared instance from the CAS
instance to the FSClassReg instance, to reduce by 1 deref the path
traversed when using the generators (or does everybody think that's
silly?).
It will minimize the changes if the CAS impl unpacks the meta data to
hold direct references to the type system and the fs class registry.
Performance-wise, it should make no difference.
-Marshall
