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 > course. > > So, what I'm thinking is that there's no particular value in not allowing 3) - > the user could cause a runtime error in either case; > but not doing 3) would make UIMA "get in the way" of coders trying to get > their > work done :-) - for the case where they were doing proper type casting. > > On balance, it seems to me to be better to allow 3.
I have to admit, I'm surprised to see you arguing this way ;) I don't strongly object, but I suggest that we should hear at least one other opinion on this. So anybody: convenience vs type-safety in uimaj-core? -> What is your "vote"? > re: using the older forms: yes, that's really not needed (except perhaps for > edge cases), so could be deprecated. At this point, I'm not sure that's worth > doing, though... I think the "point" probably isn't to badly chosen as contemplations towards a UIMA 3 have begun at which point deprecated methods could then be removed. > Here's one edge case (these are hard to think of :-) ). The coder has a type > hierarchy A -> B . They define JCas class for A, but not for B. > To get all instances of B, they would need the older format. They could still use the CAS interface which would continue to offer the method. Cheers, -- Richard
