toString() should work on all literal types

[piotrszul]

`toString()' fails for Boolean and Quantity collections.
Also it should produce {} for not literal types.

(Literal exclusions)

Details

java.lang.RuntimeException: Error invoking method-defined function

• attrtrue.toString() [** bool to string]

(FHIR R4 Exclusions)

Details

java.lang.RuntimeException: Error invoking method-defined function

• true.toString() [** testBooleanLiteralToString]

Details

java.lang.RuntimeException: Error invoking method-defined function

• 1 'wk'.toString() [** testQuantityLiteralWkToString]

[johngrimes]

I think toString is actually a new feature that has not been implemented completely, and we should go ahead and complete the implementation.

[piotrszul]

@johngrimes as far as I understand the fhirpath spec toString() should be implemented for all types including the complex elements types for which it returns empty collection '{}'.
Out current implementation uses StringCoercible to check which columns can be exported by extract in 'FLAT' mode (e.g. to CSV) and fails is any of the column cannot be converted to string.
Should we preserve this behaviour - that is fail when any of the columns is of a complex type (except for our FHIR primitives) or should we return NULL in such cases?

[johngrimes]

I think we should return an empty collection for complex types.

[piotrszul]

I think we should return an empty collection for complex types.

@johngrimes OK. But what should we do in extract() (to csv) (as in in the server) for complex types.. Return an empty value or fail?

[johngrimes]

I think that these two are separate issues:

• What toString returns for a complex type
• How we represent an empty collection in an extract result

I think we already have an established behaviour for representing empty collections in extract.

[piotrszul]

I think that these two are separate issues:

• What toString returns for a complex type
• How we represent an empty collection in an extract result

I think we already have an established behaviour for representing empty collections in extract.

@johngrimes yes, but the third issue separate from these is if we want to use 'toString()' when creating flat (csv) extracts. We could and then complex types would be exported with empty values (whatever the representation) or we could choose to preserve the current behaviour and fail when such an export is attempted.