The role of DataValue#id

[mtf90]

I'm currently trying to clean up generic type definitions and wanted to make the DataType class typed according to its given base type Class<T>. I assume the intention is that upon creating a DataValue(type, id) the id should always match the specified type?

The problem I encountered is that Parameters (or SymbolicDataValues in general) are implemented as DataValue<Integer>. Now, for example, the ParValuation constructs from a given (word of) PSymbolInstance parameters using the symbol's DataValue<?> types but assigns to it an integer id which causes the compiler to complain (rightfully so, because instantiated symbols may reference non-integer types).

Throughout the code, I have only found calls to DataValue that set a numeric value for the id field, so would an int id field be more appropriate? This would mean that we expect users to encode parameter values with a symbolic identification themselves. If arbitrary (but apparently unrelated) types should be supported, maybe Object would be a better fit than a generic type? In this case, given the discussion #73, what remaining use does the base class have, if the name alone seems to be the primary identifier for a type? Or should the current SymbolicDataValue implementation be decoupled from DataValues?

[FredrikTaquist]

I would be in favor of decoupling SymbolicDataValues from DataValues. In a DataValue, the id field is a concrete value, whereas in SymbolicDataValue, the id field is the index of the parameter, which is not really the same thing. But I would like to hear what others think.

[mtf90]

This would be my preferred solution as well. I would also rename DataValue#id to DataValue#value to make its role more obvious.

[mtf90]

The decoupling breaks VarMapping because Mapping expects it value type V to be bounded by DataValue. I can workaround this by adding another layer of abstraction, but I would much rather want to replace Constants, ParValuation, etc. with regular Map<X, Y> types.

I get the appeal of domain-specific classes, but most of them are just type aliases. Given that most consumers of AutomataLib/LearnLib/RALib are programmers, they probably understand Map<X, Y> much faster than reading up on the semantics of 5-6 custom classes anyway. Or do you know of any use-cases where these subtypes are explicitly required (aside from utilities such as the ParValuation constructors, etc. -- these can be easily moved)?