Thilo Goetz wrote:
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).
Could this could be phased in later - or do you think it would be
important to do now?
I don't see a strong need to add this other new class, myself, but that
could be because I haven't spent much time
thinking about this.
There are other things in the CAS impl that could be shared among
different CASes sharing a type system.
Some of them include the arrays: featureOffset, fsSpaceReq, and
creatable Type. Moving these into the typeSystemImpl
would compute these things once, when the type system was "locked". Do
you think this is a good idea?
Methods like initTypeVariables and initTypeCodeVars also seem to belong
to the typeSystemImpl - in that they could
be run once, automatically, when the type system is "locked". Does this
seem right?
Thanks. -Marshall
