Le 22 sept. 09 à 12:50, Andre Merzky a écrit :
[...] A possible solution could be to modify the current saga::rpc::parameter class to be an abstract class which is "derived" into two different subclasses: the first one encapsulates a saga::buffer and is similar to the current saga::rpc::parameter and the second one implements the new data handle. But maybe there are other ways to proceed (using an interface ?) avoiding to change too deeply the current rpc::parameter class.
I think that this would be the cleanest solution.
It may be useful to add some rudimentary means for inspection to the abstract class, like get_type() which would return an enum 'Buffer' or 'Handle' - what do you think? That would also simplify implementations which only support one type.
Yes, it is a good idea. We can also maybe add a type for the containers. So we would have classes like that: package saga.rpc { ... enum parameter_type { Buffer = 0, Handle = 1, Container = 2 } class parameter : extends saga::object { /* private constructor. For SIDL definition, just do not define it. * For the implementation it should look like that: * CONSTRUCTOR(in parameter_type type, * out parameter obj); */ get_type(out parameter_type type); } class buffer_parameter : extends parameter { /* We use the same constructor that the previous saga::rpc::parameter * In the implementation it calls the constructor of the inherited class: * parameter(Buffer) */ CONSTRUCTOR (in array<byte> data = "", in int size = 0, in io_mode mode = In, out parameter obj); ... } class handle_parameter : extends parameter { /* In the implementation the constructor calls parameter(Handle) */ CONSTRUCTOR(in array<int> dim_sizes, in array<uri> input_uris, in array<uri> output_uris, in data_type type, in array<data_mode> data_modes out parameter obj); ... } ... } With these definitions, we have an uniform way to call a service regardless to the data type (buffer, handle or container). Moreover, the containers can also manage these different types.
Well, that would make the class concrete (i.e. not abstract), but so what? One could leave the constructor private, so that the user cannot accidentically create the base class itself...
Just thinking out loud here...
Indeed, I think this is a good way to prevent such a problem. Gaël.