firely-net-sdk
firely-net-sdk copied to clipboard
FirelyTeam
Make all common classes that are used in the main sdk public (some are internal)
The main version-specific assemblies use some classes in the common shared assemblies that are declared internal instead of public (e.g. Hl7.Fhir.Serialization.PocoBuilder).
This works because the common assemblies have InternalsVisibleTo attributes referencing the released version-specific assemblies, but this prevent forked version of those to use the common ones.
I don't like to do that in general, we make a very deliberate choice of making things public or not. Public surfaces need to be documented and need to be kept stable. Especially that last bit is biggie. We do try hard to keep the SDK stable, and making everything public by default means we will have trouble to refactor, rework, improve, speed up etc. without breaking an interface. It took us a while (a few years of maintaining this SDK) before we understood why Visual Studio makes new classes internal by default ;-)
That being said, this is not cast in stone. If one of the internal classes provide useful functions, or it becomes too hard to use or customize the SDK without having some classes public, we should consider doing that. Or look at how we can provide controlled public access to some of the internal/private parts without exposing it all.
So, to get that discussion started, would you argue the PocoBuilder needs to be visible publicly? Which parts/functions would you need?
would you argue the PocoBuilder needs to be visible publicly? Which parts/functions would you need?
I cannot really argue one way or the other - we forked your main SDK (https://github.com/CareEvolution/fhir-net-api) - to create a library that works across FHIR versions. That fork uses the 'base' common libraries (Hl7.Fhir.Support etc.) as NuGet packages. Now I am trying to use the latest version of those packages but I am getting stuck because the code I am trying to adapt / copy from uses internal classes that our fork cannot use (being internal...). I am open to any suggestion . . .
