property: Add convenience overloads to isValid()

[jonaskello]

Currently we have this:

export function isValid(
  properties: PropertyValueSet.PropertyValueSet,
  filter: PropertyFilter,
  comparer: PropertyValue.Comparer = PropertyValue.defaultComparer
): boolean;

I propose that we add the possibility to pass unparsed strings to the parameters:

export function isValid(
  properties: string,
  filter: PropertyFilter,
  comparer: PropertyValue.Comparer = PropertyValue.defaultComparer
): boolean;
export function isValid(
  properties: PropertyValueSet.PropertyValueSet,
  filter: string,
  comparer: PropertyValue.Comparer = PropertyValue.defaultComparer
): boolean;
export function isValid(
  properties: string,
  filter: string,
  comparer: PropertyValue.Comparer = PropertyValue.defaultComparer
): boolean;

This could be done as overloads of the existing isValid() function without a breaking change. Not that I in particular like overloading, but the alternative would be to have 4 separate named versions. I find it hard to come up with good and short names for all 4.

[jonaskello]

Actually overloading is not needed, we can just do union types instead:

export function isValid(
  properties: PropertyValueSet.PropertyValueSet | string,
  filter: PropertyFilter | string,
  comparer: PropertyValue.Comparer = PropertyValue.defaultComparer
): boolean

[jonaskello]

Actually it cannot be done by neither union types nor overload since when we have raw strings there is a need for a UnitLookup function, but when we get parsed values (as in the current version) this is not needed. This means we would have varying number of parameters in the overloads which AFAIK is not supported by typescript.

UPDATE: It is possible to have different number of params in the overloads as long as the implementation supports all permutations. However this is a bit messy to implement because of the optional comparer param. But it should be possible.

[jonaskello]

One issue with the overloads is that since they accept a string, the parsing of that string may fail. It then becomes a question how to handle the failures. The two main paths are :

• Built-in behaviour, like throwing an exception, or just defaulting to an empty PVS and/or PF
• Returning a result to let the application handle the parse failure