If type inferencing from the surrounding context wasn't done, and the user
needed to cast the result, the user would be exposed to the same runtime
error. So, unless there's some other pros/cons, it seems to me it would be
best to allow generic type inferencing in cases where there's a
I agree that (3) is not safe. However it imposes a burden on the user
(assuming they want to use some method that's in the type but not in TOP) to
cast the result to the type. This cast could also throw a runtime error, of
course.
So, what I'm thinking is that there's no particular value in
On 08.07.2015, at 17:11, Marshall Schor m...@schor.com wrote:
I think that similar arguments apply to other getters, such as
getAnnotationIndex(some-type-spec).
These are currently defined to be generic methods so they do type inferencing.
True.
Mind, I'm arguing for the conservative and
I think that similar arguments apply to other getters, such as
getAnnotationIndex(some-type-spec).
These are currently defined to be generic methods so they do type inferencing.
-Marshall
On 7/8/2015 9:24 AM, Marshall Schor wrote:
More about the signatures and type inference.
We have the
On 08.07.2015, at 17:14, Marshall Schor m...@schor.com wrote:
I agree that (3) is not safe. However it imposes a burden on the user
(assuming they want to use some method that's in the type but not in TOP) to
cast the result to the type. This cast could also throw a runtime error, of
So long as the Runtime error is meaningful and documented then I vote for
option 3. T extends TOP still limits the user to the family of the UIMA
universe so to speak without limiting them to an explicit FS inheritance which
is a useful flexibility in spite of the risk of a casting error.
OK. Based on the previous discussion in this thread, and at least one other
person posting their view in favor of type inferencing (vs. safety), I'm going
to allow (3) to have type inference.
-Marshall
On 7/8/2015 11:17 AM, Richard Eckart de Castilho wrote:
On 08.07.2015, at 17:11, Marshall
I think I see another reason to allow type inferencing, which is less user code
starts failing to compile when adopting 2.8.0 from 2.7.0. This is because user
code in 2.7.0 could have done:
FSIteratorMyAnnot = myJCas.getJfsRepository().getAllIndexedFS(MyAnnot.type);
and it would work in 2.7.0
Burn reports a source incompatibility with the 2.8.0 signature for the
getAllIndexedFS. This is a somewhat complex issue. Here's what I've found so
far:
1) We have 3 sets of versions of getAllIndexedFS - one in the plain CAS index
repo, one in the JCas version of the index repo, and one
A good reference:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#FAQ303
-Marshall
On 7/7/2015 3:37 PM, Marshall Schor wrote:
Burn reports a source incompatibility with the 2.8.0 signature for the
getAllIndexedFS. This is a somewhat complex issue. Here's what
On 07.07.2015, at 21:37, Marshall Schor m...@schor.com wrote:
Burn reports a source incompatibility with the 2.8.0 signature for the
getAllIndexedFS. This is a somewhat complex issue. Here's what I've found
so far:
1) We have 3 sets of versions of getAllIndexedFS - one in the plain CAS
11 matches
Mail list logo
