Thinking in how our intellisense works, we need classes generated... thinking on how FHIR work, we will need to use non-persistent objects but with features like the ones that inherite from %Dynamic*** or the ones that make use of %JSON.Adapter... so one (very general) idea would be to start from the JSON schema of a FHIR release or profile with which you need to work and have a tool that automatically generates the classes that map such schema... and those classes have to have the easiness to export/import JSON documents that %Dynamic* and %JSON.* packages give us.

We should have in mind that these are intermediary packages, no need to persist, we just need them to help us for having intellisense when manual programming FHIR resources, also to help in DTL definitions, etc... so we could have several packages, one for each FHIR release/profile we want to use: r4.*, r4uscore.*, r5il.*,... in the end the objects instanced will inherit for a common class of type %<SomeKindOfNew>DynamicObject.... that provide the helpful logic to use %ToJSON, %FromJSON, %BulkExport,... and to be used in DTL definitions from HL7 to r4.* resource... DTL from r4.* to r5.* resources,... and the capability to be easily serializable or work as virtual document if needed to be sent within our interoperability framework...

Just thinking aloud

Right. But we should have a quicker way to get the parameter in our Python code.


set r = ..#MYPARAM


r = iris.cls('MyPackage.Subpackage.ClassName')._GetParameter('MYPARAM') 

doesn't seem too "developer friendly" to me wink

By the way, it varies if we're in a ClassMethod or in an instance Method. In instance we could do:

r = self._GetParameter('MYPARAM') 

which it's more acceptable...

But, in a classmethod it seems that our only chance would be the long version.

I wonder if we could translate them to Python as read-only special properties, adopting perhaps some convention in their name to avoid the conflicts in the (unusual) case that there is a parameter with same name that a property.

Interesting summary. Even as a Windows user I'll bockmark it to take a closer look... regarding the terminal... give it a try to Windows Terminal Preview...available in Microsoft Store... sure you'll like it.

Also for screen snapshots... if you want to have the chance to decide where to store it... use this option 

that you'll find in Windows Ink workspace... (the one you get rid of :-)  ) ... it'll capture the whole screen and open it to let you cut, modify and copy or save the image...

I think that that's not valid as "in theory" he doesn't know the name of variables. I would try this:

ClassMethod Indirection()

    set TABLES(0)="EVEN"
    set TABLES(1)="ODD"
    for i=1:1:100
        set table = TABLES((i#2))
        set @table@(i)=

    zw @table
    set evenTotal=0
    set i=""
        set i=$ORDER(@table@(i)) QUIT:i=""  
        set evenTotal evenTotal+@table@(i)
    zwrite evenTotal

Hi again, I've just added to the article the slides that I used during the video tutorial. Feel free to use all of some of them. If you do, the only thing I would kindly ask you is to include a link as a reference to this article within our community.

For the ones that contacted me, you were right, the repository in GitHub was set as private. It's set to public now: GitHub Repository - Examples 

Well, it has been a long trip... but Chapter 6, "What's about SQL?" is finally published with reviewed English CC...

In this last chapter I'll show you what's about the Multi-Model architecture of InterSystems IRIS, and how ObjectScript is able to work also with SQL paradigm in a very easy way to also cover that feature of the platform.
We'll do hands-on exercises of embedded and dynamic SQL using the small class model we defined in the previous chapter... which now we'll see as an E/R model.

And... That's all folks!

Happy Coding!

Yep, I know. But I hoped something more "transparent"... if we deal with several instances and change with certain frecuency (as it's my case), having to define direct accesses when we have a link in the "cube" menu, doesn't seem too clean. For Linux/Mac users, the solution is clean. You just define your aliases file, and you just can install your IRIS instances... all of them would make use of them seamlessly... that's the functionality. Right now, for windows users, it's incomplete. A pity because it's a really very good feature to have, our terminal/shell needs these kind of tools, but it has to be much easier to reuse among instances.  IMHO. 

Perhaps it would be as easy as to change our installer so to include that argument out-of-the-box in the call to Terminal in the cube... and then let the developers build their own script in their own home directory.

Now just needs to be a way to "import it"/"preserve"/"make it easier" in Windows systems, to cover the other 70% of people. wink