Archived

This forum has been archived. Please start a new discussion on GitHub.

Enhancement: Add default values to slice definitions

joshmoore
joshmoore Germany
in Comments
Just a quick suggestion, without knowing how practical it is: it'd be very convenient to be able to specify default values in the slice mapping files.
module omero {
    module grid {
	class JobParams {
	    string name;
	    string description;
            int timeout = 30; // Seconds
            ...

Though there may need to be some restrictions on how many, what types, etc. this could simplify using constructors significantly.
# python

class JobParams:
    def __init__(self, name, description, timeout = 30):
        ...
j = omero.grid.JobParams("name", "description")

// Java
public class JobParams {

   public JobParams(String name, String description) {
       this(name, description, 30);
   }
...

Comments

  • michi
    michi
    Doing this would be problematic in the face of the various language mappings. For example, with C++, a Slice struct with such an initializer would require the generated code to add a constructor to the corresponding C++ structure. However, that would prevent the structure from being used as a POD (plain old data type) and prevent static initialization.

    There is also the issue of run-time overhead. For example, when unmarshaling a sequence of structures, we would incur the overhead of default-initializing each structure in a vector, only to then have to overwrite the contents of the structure with the unmarshaled data anyway.

    In general, default initialization such as you suggest is an implementation concern, but Slice is an interface definition language. In other words, Slice is almost certainly the wrong level of abstraction to implement such a feature.

    One way to achieve what you want is to define a sub-class or sub-structure in your application code. For example:
    // C++
class MyJobParams : public JobParams // JobParams generated from Slice
{
public:
    MyJobParams() { timeout = 30; }
};

    If you want an initialized class, simply instantiate MyJobParams. Because MyJobParams derives from JobParams, you can pass that instance whereever a value of type JobParams is expected.

    Cheers,

    Michi.
  • joshmoore
    joshmoore Germany
    Hi, Michi. Thanks for the response. Obviously, this is more of a pie-in-the-sky wish, so no hard arguments from me below, but a few thoughts.
    michi wrote: »
    Doing this would be problematic in the face of the various language mappings [...] would prevent the structure from being used as a POD (plain old data type) and prevent static initialization....There is also the issue of run-time overhead. For example, when unmarshaling a sequence of structures, we would incur the overhead of default-initializing each structure in a vector, only to then have to overwrite the contents of the structure with the unmarshaled data anyway.

    Definitely understood. As I mentioned there would need to be either restrictions on such a feature or a clear description of the performance penalties.
    michi wrote: »
    In general, default initialization such as you suggest is an implementation concern, but Slice is an interface definition language. In other words, Slice is almost certainly the wrong level of abstraction to implement such a feature.

    In most cases, but as with the JobParams this is actually a DTO to permit complicated parameters to be built up for a single method invocation. I.e. something between an interface and an implementation concern.

    On the other hand, default values would be just as useful in interface methods, which would be the case here if I were to flatten JobParam into a long argument list.
    michi wrote: »
    One way to achieve what you want is to define a sub-class or sub-structure in your application code.

    Sure. My current issue as with JobParams is attempting to unify multiple language bindings for a single API. Dealing with default values at the subclass/object-factory level feels strongly of repetition, and I was looking for a way to delegate that to the code-generation.

    Again, thanks for the consideration.
    ~Josh.

Categories