On 8/9/2013 11:19 AM, Richard Eckart de Castilho wrote: > Am 09.08.2013 um 15:49 schrieb Marshall Schor <[email protected]>: > >> On 8/9/2013 9:18 AM, Richard Eckart de Castilho wrote: >>> Actually, I think that in is questionable whether the type should be >>> extensible in either of the two fashions. Anybody who wants to store >>> additional meta data in a CAS could create a custom type instead of >>> modifying DocumentAnnotation either through the officially documented was, >>> through type merging, or through derivation. >>> >>> Do you suggest that only derivation should be prohibited, but type merging >>> should be allowed, possibly even encouraged? >> I think it should be discouraged, but want to have our user community to >> continue to be happy with existing deployments (UIMA is used quite widely, >> around the world, I believe). >> >> So I don't want to introduce a change that likely would result in breaking >> many >> existing applications. > That's why I tagged this issue with the "incompatible" version. I understood > your previous comments such as that you suggested to make the > DocumentAnnotation at least feature-final. That is already an incompatible > change which would break at least Ruta and DKPro Core. My comment earlier was expressing regret that it wasn't made inheritance-final, not feature-final :-).
A main design point (for good or for worse) is that UIMA does type system merging. For the the 3.x version, we could contemplate doing just-in-time JCas class compliation at the same time UIMA does the pipeline type system merging - this would alleviate (I think, if done right) at least some of the pesky issues around pre-compiled JCas cover classes, without introducing incompatibility. > > For the sake of progress, well planned incompatibility is not necessarily a > bad thing, is it? [gingerly stepping up on the philosophical soap box] Here's my 2 cents on this: There are 2 potential sets of people to "please" with UIMA changes: One is the Users who are running stuff, and generally don't care much about archetectural things, and the Developers. Users are more important to please than Developers. For Developers, there are 2 kinds of changes: those which, via refactoring and other improvements under-the-hood (not affecting existing User code) improve speed, future maintainability and development, etc. There are other changes which "clean up" inconsistencies (only); if these cause trouble to users, I think they would need to have a pretty high level of counterbalancing "improvement" in some other aspects to be worth doing. (In other words, I think it is preferable to life with inconsistencies, etc., if they are not causing serious trouble, in order to keep the system "stable" for users). [jumping down from the philosophical soap box to avoid thrown fruit and other things ...] -Marshall
