My name is Robert Barbiaux, and I am from Belgium.
I've been interested in science and technology since 1979. At age twelve, I first encountered computing through programmable calculators and 8-bit computers like the Radio Shack TRS-80.
I hold a degree in computer science from Brussels Free University and have worked in IT since 1990 in roles including developer, analyst, system engineer, and development team leader.
Over the years, I have gained experience with IT across multiple business and industry sectors such as steel, retail, banking, and healthcare. My background includes work in various operating environments (Unix, Windows, etc.) and programming languages (C, C++, Object Pascal, Java, etc.).
My initial experience with InterSystems technologies began with Caché in 2006 while working in the healthcare sector. Since then, I have used Ensemble and IRIS Health primarily for interoperability projects and have developed expertise in healthcare IT.
Currently, I am engaged as a freelance healthcare IT consultant at a hospital, providing services as an analyst, developer, coach, and specialist in healthcare IT.
Hi Evgeny,
In ISOS, the "quit" command is inherited from MUMPS ("Q[UIT]") and has two forms (see the documentation for details) :
- with arguments : terminates a method, function or routine, returning it's arguments as value
- without arguments : exits the current context (e.g. for, while, ...)
The "return" command was introduced by InterSystems, I think in Caché 2016.2 (@all please, correct me if I'm wrong). It was added to avoid confusion, making ISOS clearer and also more aligned with 'modern' programming conventions.
"return" is equivalent to "quit" with argument, thus is has only one form and one, clear meaning : returning a value.
When the code intent is to return a value, nowadays I favor using "return".
p.s. IMHO, generative AIs, while useful in some contexts, are nor artificial, because they are trained with human sourced corpus, nor intelligent, because they are not able of any real creativity and are not doing any reasoning (even if they can mimic both rather well) 😇
Hi Evgeny,
Thank you for sharing the details, now I see why you have so much lines in a single class 😊
As an example of what Scott and Robert are explaining in their excellent answers, when dealing with a REST API spec defining (mostly) CRUD operation on many resources, I think one way to divide and, hopefully, conquer is to delegate the implementation of operations related to each resource to a separate class.
Taking as example petstore, for which, of course, this is an overkill, this would result in five classes :
- Class dc.petstore.impl Extends %REST.Impl : (generated), all endpoints class methods, with most bodies being single line call to another class method
- Class dc.petstore.Commons : logic common to all the classes below
- Class dc.petstore.PetOperations Extends Commons : class methods dealing with 'pet' resource (CRUD + other)
- Class dc.petstore.StoreOperations Extends Commons : same for 'store' resource
- Class dc.petstore.UserOperation Extends Commons : same for 'user' resource
dc.petstore.impl class methods simply delegate the call to resource class, e.g.
ClassMethod findPetsByStatus(status As %String) As %DynamicArray
{
return ##class(PetOperations).FindByStatus(status)
}Hope this helps
Thanks DC 😊