text: Enhancement: Add default values to slice definitions
  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.
  Though there may need to be some restrictions on how many, what types, etc. this could simplify using constructors significantly.
  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); } ...
  0
  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:
  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.
  Definitely understood. As I mentioned there would need to be either restrictions on such a feature or a clear description of the performance penalties.
  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.
  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.