[saga-rg] Comments on Strawman API

[Graeme Pound]

> 
> You mean that both the attribute interface and the get/set
> version should be provided?
> 

Yes, where an interface extends Attribute (such as JobInfo) it could 
define several utility get/set methods that encapsulate the semantics of 
that interface. These methods could simply store values using the 
Attribute methods.

This solution is not especially pretty, there is no encapsulation of the 
underlying storage.


> 
> 
>>>>  -5.5 Implementations could be provided for generic classes to prevent 
>>>> developers from needing to re-implementing, for example; Attribute, 
>>>> Context. Obviously implementation specific subclasses of these would 
>>>> have to be defined as 'abstract' classes. Rather I think that an 
>>>> interface only solution is simpler and more flexible in the long term, 
>>>> default implementations of generic classes could still be provided.
>>> See above: the spec talks about classes by now.  Do you think that
>>> this limits flexibility overly much?  In our opinion, the implementors
>>> of SAGA have the same flexibility as before, and the users of SAGA
>>> don't need it, really.  What do you think?
>> I am not clear about the interface/class distinction in SIDL.
>>
>> In the Java world interfaces are more *fashionable* than class 
>> inheritance. There is little to be gained from abstract classes apart 
>> from tying developers to code defined by the language bindings. It is 
>> also harder to introduce a bug into a Java interface.
>>
>> The purpose of the SAGA API is to define an interface. The 
>> implementation developers are not tied to an implementation of the 
>> utility classes, and the users should not care.
> 
> I am not sure about the implications either, but one thing
> which keeps popping up is that Java interfaces can't have
> constructors.  However, the API specifies a number of
> constructors, so, in Java, that would defy the interface
> only approach - how do you handle that?
> 

Java interfaces are the most flexible approach, especially since Java 
does not support multiple inheritance.

When you look at the issue there are good reasons for interfaces not to 
support constructors. It is a pain but just something that has to be 
lived with. We must expect developers to honour the documented 
constructors for an interface.

Another solution (which I like) would be to extend the concept of 
factory classes (already used within the SAGA API). The constructors 
could then be defined by the methods of the factory class(es).

Factories would also assist the dynamic loading of SAGA implementations 
at runtime.

Graeme