Problems should provide more than operators to algorithms

[ascheibe]

Currently IProblem provides a collection of IOperators which an algorithm can query. We should change this to IItems which would enable algorithms to use problem-specific functionality which is not an operator. The current use case are diversity measures which are not operators but used by other operators.

[ascheibe]

r7999

• switched IOperators collection to IItems
• adapted algorithms and problems
• added AfterDeserialization hooks for problem, external evaluation problem and user-defined problem

[mkommend]

r8004: Corrected deserialization of the operator collection.

[abeham]

I wonder why the scheduling branch didn't fail.

[ascheibe]

I just checked the scheduling and MetaOpt branch, they compile and there are also no potential problems that could result from trying to cast IItem to IOperator. Scheduling doesn't fail because it doesn't implement it's own operators collection like some other problems do.

[ascheibe]

Replying to ascheibe:

I just checked the scheduling and MetaOpt branch, they compile and there are also no potential problems that could result from trying to cast IItem to IOperator. Scheduling doesn't fail because it doesn't implement it's own operators collection like some other problems do.

And the same thing also holds for MetaOpt.

[mkommend]

I reviewed the changes in r7999 and everything works. As I have also made changes in r8004 I forward this ticket to you for another revi

[ascheibe]

I have reviewed the changes. Looks good, thanks.