[CLEANUP] Add an interface for components of a property value

[JakeQZ]

Resolves #499.

[oliverklee]

Looks very good to me in general.

I think this deserves an entry in the changelog.

Also, we should update the class diagram to integrate the interface and to update the associations to use the interface (maybe after #505 is merged).

[oliverklee]

We also should make sure that the name makes sense globally (as Mermaid on GitHub doesn't allow namespaces). Maybe CssPropertyValueComponent oder PropertyValueComponent?

[JakeQZ]

We also should make sure that the name makes sense globally (as Mermaid on GitHub doesn't allow namespaces). Maybe CssPropertyValueComponent oder PropertyValueComponent?

I don't think whatever limitations of Mermaid there may be should dictate class naming conventions. Mermaid might in future be enhanced to show the namespaces. We should choose the most apt names for classes, interfaces and namespaces independently of whatever other tools we use.

The FQN is Value\Component. The namespace Value could perhaps be PropertyValue (or Property\Value) for clarity, though any such rename would be beyond the scope of this PR, and probably unnecessary (it would be a breaking change).

[oliverklee]

Also, we should check if there are any common methods that should be part of the interface so the interface is more than just a marker.

[JakeQZ]

Also, we should check if there are any common methods that should be part of the interface so the interface is more than just a marker.

Looking again, I don't see any common methods, but do see that all of these classes extend Value, which implements Renderable. A Value can be a simple value, or a complex value comprised of simple values connected with operators.

So perhaps a better approach would be to simply use the Value type whenever any of the various subclasses is expected, and not introduce a new type (or interface) at all.

[JakeQZ]

Looking again, I think instead we should just use the existing ancestor Value type to replace the long list of possible subtypes in the annotations, rather than adding a new empty interface.

Also, we should update the class diagram to integrate the interface and to update the associations to use the interface (maybe after #505 is merged).

Yes. (I need to get up to speed on that.)

[oliverklee]

I think instead we should just use the existing ancestor Value type to replace the long list of possible subtypes in the annotations, rather than adding a new empty interface.

Sounds good to me.