RealVectorAdditiveMoveWrapper is visible through the discovery mechanism

[cneumuel]

HeuristicLab.Problems.TestFunctions.RealVectorAdditiveMoveWrapper is not a storable class. It should be one!

Update: I still think it should not be storable, but I removed the default constructor to prevent discovery.

[abeham]

Why?

It does not live beyond the scope of the move evaluator's apply method and will thus not get serialized.

[cneumuel]

When configuring a MetaOptimization parameter tree, it can be a possible operator of a parameter. When this parameter configuration tree is stored, those possible operators also need to be stored.

[abeham]

The RealVectorAdditiveMoveWrapper is not an operator. I don't know what you're doing, but you shouldn't use this data type in any way.

Here is the scope where it lives:

protected override double Evaluate(double quality, RealVector point, AdditiveMove move) {
  RealVectorAdditiveMoveWrapper wrapper = new RealVectorAdditiveMoveWrapper(move, point);
  return AckleyEvaluator.Apply(wrapper);
}

It's not meant to be used in any other context.

[gkronber]

I guess the problem is that RealVectorAdditiveMoveWrapper is a RealVector. Thus, automatic discovery of all possible values of a RealVector parameter also returns an instance of this class.

[abeham]

How can I prevent such a discovery? Would it be enough to kill the default constructor (which doesn't make sense anyway) so that a default instance cannot be created?

[abeham]

I will remove the default constructor.

[abeham]

r5058

• Removed default constructor to prevent discovery

Please check if this solved your problem, otherwise we'll make it Storable.

[cneumuel]

The current solution throws an exception when the type is discovered. This can be verified with the following code:

var items = ApplicationManager.Manager.GetInstances(typeof(DoubleArray)).ToArray();

Exception: System.MissingMethodException: No parameterless constructor defined for this object.

The exception is thrown directly in LightweightApplicationManager.GetInstances and is uncaught:

    public IEnumerable<object> GetInstances(Type type) {
      return from t in GetTypes(type, true)
             select Activator.CreateInstance(t);
    }

Now, I certainly could catch the exception in my code, but this implementation would make it possible to break other plugins by introducing types without parameterless constructors. In my opinion either the ApplicationManager should catch the exception (1), or types which must not be discovered should be attributed with something like [Undiscoverable] (2).

(1) has the disadvantage that types which accidentally have no parameterless constructor can be introduced without any warning.

(2) would force the developer to think about the type discovery mechanism which i think is OK for types which should explicitly not be discovered.

[swagner]

Implemented solution (1) in r5131. Solution has been reviewed by abeham and mkommend.