On 1/4/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
>> - On the JCas interface, can we remove some of the APIs and just make
>> them available on the impl object? I'm thinking of things like
>> putJfsFromCaddr(int, FeatureStructure) and getType(int).
>>
>
> I think these may be called from JCas cover-classes, in which case I
> think they need to be on the interface. Marshall?
The "putJfsFromCaddr" is called from the JCas cover-classes. It could
be in impl, though - we could change JCasGen and the migration tool.
Then the JCas cover class would have to do a typecast, and require
that the JCas passed to its constructor was in fact a JCasImpl, which
doesn't seem good (unless I'm missing something).
I don't think we have compelling enough reasons to require users to
a) getViews from CASes, and also then b) dereference from the View back
to CASes to do
the real work of creating / accessing / updating Feature Structures.
I think that the APIs for users should focus on what the users need to
get done, with an eye toward
economizing on the verbose-ness of the resulting code (sorry - I mean to
say, the user's code should be very "readable" - and having
dereferencing chains makes
it less readable, I think).
I think users object more to the "write-ability", which is partly how
many keystrokes you need but also just how easy it is to learn and
remember what it is you're supposed to write.
Readability is subjective... We need to be clear on with what the
concepts we're trying to communicate are. The code
view.getCAS().createFS(...) may be considered more readable if it's an
important concept that FeatureStructures are created on the CAS, not
on a view.
However, are we sure that's such an important concept? What if we say
that a CasView is a particular "window" on a CAS, a way of looking at
it. That seems kind of consistent with the word "view". And it
doesn't then seem so bad that you can make changes to the CAS through
the view, such as adding FeatureStructures.
-Adam