Hi,
Am 09.09.2016 um 23:24 schrieb Joern Kottmann: > My point is about b when someone is using Jcas the compile time static > typing is forcing these types into me type system and the classes have to > be on my classpath. It is impossible to use Jcas and not force the types > into other people's type systems. And my opinion is that this is just wrong. I disagree. For me, the type system is the part of API of the component. You need the API in order to use the component. > A framework like Uima has to make it easy to reuse components and in my > opinion strict compile time typing makes that really difficult to achieve. Components are already very reusable if they use the same typesystem. Again, that has nothing to do with compile time typing. And, this is not the only purpose but there are many more, e.g., allow the developer to create large maintainable pipelines. In my opinion, components in UIMA are much more reusable because of the static typing, not just throw-away prototypes. > > But maybe I am wrong and people have some good examples of Jcas based AEs > which are nice to reuse in a simple custom pipeline. > I am not interested in simple pipelines. I do not need UIMA for that. I need UIMA for pipelines with dozens of components developed by different people. Good example of a JCas-based AE: every AE that was developed to solve a specific task for well-defined semantics defined in a type system. Jörn, if you do not provide constructive arguments or a specific reasonable use case, but just complains, there is no reason for me to continue this discussion. Best, Peter > Jörn > > On Sep 9, 2016 17:58, "Marshall Schor" <[email protected]> wrote: > >> Hi Jörn, >> >> I think people really want to understand the details about why: >> >> a) you are forced to use JCas just because an AE is using it (I assume you >> must >> mean, outside of that AE). Other AEs don't need to use the JCas, so I'm >> misunderstanding something I think, about your point. >> >> b) why JCas isn't acceptable (specifics?). I understand wanting APIs that >> allow >> "dynamic" specifications of types, which UIMA has in its plain CAS APIs. It >> sounds like you see no benefit from what I'll call "compile-time" static >> typing >> style of APIs, which the JCas implies; is that what we're discussing? >> >> Thanks again for your input! >> >> -Marshall >> On 9/9/2016 10:09 AM, Joern Kottmann wrote: >>> Well you are forced to use it when you have to use an AE using it. >>> I think the problem with the JCas is that people think, because we are >>> offering it as part of UIMA, that is is acceptable to use it, but the >> truth >>> is it really isn't. If it would be me deciding, the JCas would be the >> first >>> thing >>> I would throw away for UIMA 3 (and also many other things). >>> >>> Jörn >>> >>> On Fri, Sep 9, 2016 at 4:00 PM, Richard Eckart de Castilho < >> [email protected]> >>> wrote: >>> >>>> On 09.09.2016, at 15:49, Peter Klügl <[email protected]> wrote: >>>>> I get the point with code generation though. >>>>> >>>>> Am 09.09.2016 um 15:11 schrieb Joern Kottmann: >>>>>> I am personally think the convenience the JCas brings is outweighed >> many >>>>>> times by all the complexity >>>>>> and disadvantages which come with it, e.g. code generation step, >> having >>>>>> extra special classes and mostly impossible >>>>>> to reuse the written code. >>>> Again, nothing forces anybody to actually make use of the JCas. >>>> If it does not match your taste, then do not use it. >>>> >>>> If you find the CAS interface to be lacking some convenience, >>>> check out the getFeature() and setFeature() methods in uimaFIT FSUtil >>>> and also the CasUtil select* methods in uimaFIT. >>>> >>>> Cheers, >>>> >>>> -- Richard >>
