Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide on whether we need Value #2925

Open
ewoutkramer opened this issue Oct 17, 2024 · 0 comments
Open

Decide on whether we need Value #2925

ewoutkramer opened this issue Oct 17, 2024 · 0 comments
Labels
idea Something to think about

Comments

@ewoutkramer
Copy link
Member

Although it sounds like we do, there might actually be a better way to get at the value. Consider: not every node has a value, since not every node is a primitive. Just like not every node is comparable or not every node is bindeable. It is probably better to have the nodes that have any of these traits to implement an explicit interface. E.g. we could have a totally separate interface IPrimitiveData, just like the nodes might implement IComparable. FhirPath and the validator really ever hardly need to inspect the values, and certainly, if these values involve parsing or conversions (e.g. from POCO values to CQL values), we shouldn't do it by default.

We might even consider expecting any leaves in a tree to always be a POCO, preferably the ones we have defined for primitives. Why would an ElementNode tree not use POCO's in its leaves? It would automatically profit from the equality, comparisons and other features of those pocos, instead of defining them again in terms of ITypedElement (as is the current situation).

@ewoutkramer ewoutkramer added the idea Something to think about label Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea Something to think about
Projects
None yet
Development

No branches or pull requests

1 participant