Thilo Goetz wrote:
<snip> I think it's useful to recognize there are sofa-aware
components, and sofa-unaware components. Most of the components so
far are sofa-unaware ones - although this may change somewhat over
time. I think it is useful to make writing sofa-unaware components
"easy" in the sense of not forcing these to deal with multiple
sofas/views concepts. This is what is driving some of the design
thinking, I believe, not just trying to be "backward compatible". I
also think this is useful for UIMA adoption - in helping new users
climb the learning curve - initially they would be able to ignore
multi-sofa/ multi-views.
But that's not what the proposal suggests. In the current proposal,
the view methods on the CAS are deprecated.
I'm suggesting we think about that... and maybe not deprecate them for
sofa-unaware components.
<snip> I question the need for backward compatibility for
Sofa-unaware annotators. Those days are over. This basic tenet
robs us of the ability to clean up the CAS APIs. For example, when
I look at the CAS APIs from a world where views are real, I
naturally expect CAS.getIndexRepository() to return all indexes in
the CAS to me, not just the ones for the default view.
In the case where the world is one where "views are real" - that
naturally feels like the case of a sofa-aware component.
- For sofa-aware components, I would expect this call to be invalid
(as a User), because Index-sets "belong" to Views, and the CAS isn't
a view.
- For sofa-unaware components, I would expect this to work as before
- this is more like the case where "views aren't real".
This contradicts the "everything is accessible from the CAS without
views" axiom.
My assumption here was that we'd provide other capability for this -
such as a simple getAllFeatureStructures method (or whatever we were
calling it in previous email chains).
<snip> From a documentation point of view, I hope to have it both
ways - by describing the JCas and Cas APIs as including the CommonCas
API (which of course it does, as a super-interface). So the users
won't need to pay attention to this detail of abstraction; they can
ignore the CommonCas API as a separate entity. The current IDEs like
Eclipse support this, too (e.g., autocompletion shows the whole set).
The JCas is a wrapper around the plain old CAS. If we position it
that way, we don't need a common ancestor. Why doesn't the JCas just
extend the CAS interface, if it inherits that many functions?
This was considered. One reason it wasn't done was because some methods
return different Java types in the two impls, and that isn't allowed in
the Java model. Also, it doesn't inherit (in the current design) *all*
the CAS methods. For instance, the methods for manipulating Feature
Structures that use the Type System "handles" are not implemented,
because the JCas is supposed to be an alternative to those.
- Re: CAS/CasView design, another summary Marshall Schor
-
