Quoting [Ga?l Le Mahec] (Sep 23 2009):
Yes, it is a good idea. We can also maybe add a type for the containers.
So we would have classes like that:
Some suggested changes below:
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
This one should then also inherit saga::buffer I guess.
{ /* 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); ... }
...
What would a container_parameter look like? I am not sure I understood that one, yet.
}
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.
Nice, looks like things are converging :-)) Best, Andre. -- Nothing is ever easy.