Hartmut Kaiser wrote:
I all agree to change it this way, even if I'm a bit hesitant to do so, because it involves an almost complete rewrite of our existing C++ SAGA implementation (at least as far as tasks are involved) and breaks backwards compatibility. Additionally I find it - let's say amusing - that after long discussions around templates, which have been furiously rejected mainly by Java people, we are now back to templates. Is this because our well respected colleagues using Java suddenly discovered to have templates available in newer versions of the language? SCR. :-P
Well, as both the "origin" of this change and one of those respected colleagues using Java, I cannot not react to this. I haven't been involved in SAGA for very long, so don't know about the history or any of the discussions that have been going on about templates and/or Java. I just found the way in which tasks were supposed to return their value ugly and cumbersome, because there was no protection against accessing the result value before the task is finished. Therefore I suggested to Andre to do it differently, and to obtain the result from the task object in some way. You don't need generics or templates to do it, you could use type casts as well, but using templates would make it compile-time type-safe.
Leaves us with the question if this is implementable in other languages as well, such as C, FORTRAN or scripting languages. I'm not sure if that's possible. Especially scripting languages often rely on runtime polymorphism, not compile time polymorphism. Wouldn't it be better to leave the templated interface as an implementation detail and just to require to store the result inside the task? As I said - I'm not sure.
I agree with this. It is an implementation detail. It is up to the implementation to provide a mechanism for obtaining the result from the task, and give an exception if this is attempted while the task is not finished yet. If the specification language used for SAGA allows for templates, I would suggest to use them, but to specify that an implementation is allowed to use runtime polymorphism instead. Ceriel Jacobs