Re: Global FS variables, another suggestion
Thilo Goetz wrote: CAS.declareFsVariable(String name, Type type) CAS.isFsVariable(String name):boolean CAS.getFsVariableType(String name):Type I would like to have an additional method like CAS.getFsVariableForType(Type type):FS so that an analysis component do not have to know the variable name, it only have to know that for a certain type a variable exist that contains the FS of interest and can retrieve it. -- Michael
Re: Global FS variables, another suggestion
Jörn Kottmann wrote: Please let me know if you think this is a good idea, and if so, if you're in favor of the dynamically typed or the pseudo-statically typed version. Can you explain what is the reason to not declare the type inside the type system ? Thanks, Jörn Jörn, I'm not sure I understand what you mean. The types need to be declared in the the type system. Adam thinks that declaring variables in the descriptor is not worth the effort, and I don't know that I disagree with him. Declaring the variables in the descriptor would have the one benefit that we could check for multiple declarations at initialization/packaging time. On the other hand, my current proposal is more dynamic as you can check if a variable has been declared, and if not, declare it yourself. Did that answer your question? --Thilo
Re: Global FS variables, another suggestion
On 1/11/07, Michael Baessler [EMAIL PROTECTED] wrote: Thilo Goetz wrote: CAS.declareFsVariable(String name, Type type) CAS.isFsVariable(String name):boolean CAS.getFsVariableType(String name):Type I would like to have an additional method like CAS.getFsVariableForType(Type type):FS so that an analysis component do not have to know the variable name, it only have to know that for a certain type a variable exist that contains the FS of interest and can retrieve it. I think Michael is onto the same point that concerns me. To use this feature, components have to agree on what variable names they are going to use. So we're creating another kind of dependency that I believe should be documented in the capabilities. Sure, people could build this themselves already, but if we make it built-in then we're strongly encouraging its use and should consider all the implications. If we had more expressive capability spec (so you could say I create/require an instance of type FsVariable with name=Foo) then that might be a way to go. I don't think getFsVariableForType(Type) would completely address the issue. There can be more than one variable for the same type, so the downstream component would still not have any idea which one it wanted to use. -Adam
Re: Global FS variables, another suggestion
Having not heard a user request for global variables, I'm a little fuzzy on the use case. However, if I understand correctly what is suggested is a combination of: 1. a new built in type with two features. 2. a slight variation on the set index, where instead of silently ignoring a duplicate FS being added to the index, an exception is thrown. 3. custom APIs for working with the features of this type. Is this right? Eddie
Re: Global FS variables, another suggestion
On 1/11/07, Eddie Epstein [EMAIL PROTECTED] wrote: Having not heard a user request for global variables, I'm a little fuzzy on the use case. I think one use case is the singleton use case. You could define a global variable called myapp.documentMetadata and set its value to an instance of myTypeSystem.DocumentMetadata. Then all your annotators could access it by getting the value of this global variable. -Adam
