Extend or update the Search DSL 'has' function to include resource type as parameter

[ellykits]

Is your feature request related to a problem? Please describe.
In FHIRCore we would want to use the nested search DSL has function however we do not know the type of the resource at the time of the execution; the current Search#has function is generic and expects a resource type.

Describe the solution you'd like
Implement an overloaded extension function that accepts resource type as a parameter without affecting the existing implementation.

Describe alternatives you've considered
As an alternative we can update the existing Search#has function to accept resourceType as a parameter instead of using generic types.

Additional context
To offer more flexibility the recommendation is to update or implement a new function with the following signature

fun Search.has(
  resourceType: ResourceType,
  referenceParam: ReferenceClientParam,
  init: Search.() -> Unit
) 

Here is the current

inline fun <reified R : Resource> Search.has(
  referenceParam: ReferenceClientParam,
  init: Search.() -> Unit
) 

Would you like to work on the issue?
Yes

[f-odhiambo]

@omarismail94 Do you mind taking a lot at this and approving if it is something we can work on resolving? Thanks!

[omarismail94]

Im adding @aditya-07 as he wrote the code for this. Aditya - is there a reason we went with a reified function as opposed to the signature that @ellykits is suggesting? I think what Elly is suggesting makes sense, but wanted to see what you thought as well!

[aditya-07]

@omarismail94 There wasn't any particular reason to make the function reified. @ellykits @f-odhiambo Please feel free to add generic has api.

[ellykits]

Thanks @aditya-07. This is noted.

[jingtang10]

@ellykits @f-odhiambo @pld can you please elaborate a bit more on how you're using this new API?

I'm guessing you have some kind of configuration that defines a search by specifying its resource type and search params and that's why the type resolution must be done at runtime?

[ellykits]

@jingtang10 In our JSON config we declare the resource type as a property see the example below:

Example config for searching Patients having some Condition

{
  "resource": "Patient",
      "nestedSearchResources": [
          {
            "resourceType": "Condition"
            // Condition resource filters
         }
      ]
}

The configuration can be used in other use cases e.g. fetching Patients with particular Observation. My PR makes it possible to provide the resource type as a parameter to the Search#has function so we can use the same implementation for different resource types with similar relationships. The existing implementation uses reified generic function that requires an explicit resource type.

[ellykits]

The implementation can be compared to the overloaded FhirEngine#get function

(with no resource type as parameter)

suspend inline fun <reified R : Resource> FhirEngine.get(id: String): R 

and this

(with resource type as parameter)

suspend fun get(type: ResourceType, id: String): Resource

[jingtang10]

@omarismail94 There wasn't any particular reason to make the function reified. @ellykits @f-odhiambo Please feel free to add generic has api.

reified is needed if at runtime (EDIT: compile time) you need to access the type information of the generic class.

But that's not really relevant in this issue.

Thanks @ellykits for providing the examples. Makes sense.

EDIT: just to add, I think about reified as "compile time generics"... it's sort of like fake generics that is essentially inlined versions of the same code with different types...