I find ObjectScript Quality very opinionated with peculiar assumptions and sometimes dead wrong.
We've been using it a lot in one of our projects because the end-customer demanded it, but we need to trun off a lot of silly rules.
It is not a tool I would recommend.
I wasn't to, but now that you mention it.
I'd like to suggest it to be an open discussion on DC.
If the two systems are at network reach you could use ECP and Remote Database(s).
Then the logic could be rather easily scripted with all the power of ObjectScript at hand.
Hi @Enrico Parisi,
I was going to say "I wasn't aware of that previous discussion", but I saw that I actually contributed to it :-(
Indeed, since February nothing has changed.
We are all busy and apparently didn't have had the time to make our own attributions.
For me, I wouldn't know how to define a CQ rule, SonarCube is Java based AFAIK and I'm not a Java tiger.
It would be great if ISC would set up a GitHub repository with rules to which we can contribute.
I am not involved in the code base that was obliged to use CQ so it doesn't bother me directly anymore.
But SonarCube has some status and if a customer demands that the code base adheres to the rules of such a tool, you're in trouble. Perfectly working code (for years) suddenly has many major and critical 'errors' and you have to explain why that is.
I think no tool is better than a bad tool.
I wouldn't know why setting up ECP isn't easy.
Super easy by the Management Portal, but it can also be scripted.
For 'useful' I'd say: just skim through your globals and copy or merge whatever you need.
Hi @Evgeny Shvarov,
I, and I think Enrico too, was talking not only of the 16 rules you've selected, but the 100+ rules that are in the product if you buy it.
As far as I can see, the 16 rules are mostly about bugs which should easily be found by simple testing.
One of the biggest problems I have with OQ is that it doesn't expand macros, which gives a lot of false positives.
For instance $$$ReturnError("Illegal argument") isn't regarded as a Return, which is in the macro definition.
The same for $$$Yes, $$$True, etc aren't recognized as legal boolean values.
Silly rules that state that you should use certain syntax formats, such as parenthesis around conditions, because otherwise it is hard to comprehend for people coming from other programming languages.
I don't have the time to go though all rules but I will illustrate with one.
Rule ID:objectscriptquality:OS0078
The title is wrong, it should be "in a method call"
The argument passed must be of the type expected by the method. When no type is defined for a parameter, a %String argument is expected.
The first part of the sentence makes sense, the second is not true for Objectscript. If no type is specified the argument can be of any type.
If this is something you want is another issue.
Sometimes you want an argument to be able to be of different types.
For instance if an argument is of type %Stream, you might want to allow a simple string as a value too.
In general I would say this is not a rule that would enhance the quality of the code.
Then the rule explanation is simply wrong.
In following code, method DoWork2 expects to receive %Numeric as argument and DoWork3 expects to receive %DateTime as argument, but in both cases receive Sample.Person and will raise a "PARAMETER error" message on runtime.
A "PARAMETER error" only occurs when supplying too many arguments in the call and has got nothing to do with the datatypes of those arguments. Besides; running the example code gives no error at all.
Then the example code has several issues, which I won't discuss right now.
In addition to what Enrico said: arguments in ObjectScript are typeless. In your example Request could be anything, it is the responsibilty of the Caller to provide, in this case, an argument of type test.UserDTO.
So the <argument> as <type> is only for documentation purposes for the Caller (and for code-completion)
There are a lot of things I disagree with, but lets start with package names.
Lower case is a major break with existing ISC packages and I don't see the reason for it.
Camel case it should be.
Commands and Functions should start with a uppercase, the same for variables and arguments.
It is stupid to make an exception for Set and Do to be abbreviated.
Using underscores in names is very cumbersome because you have to use quotes around it.
Although OpenAPI and Swagger are great tools to describe and document an API, they are not REST exclusive.
In fact the examples you provide such as "/login" are RPC style API's, which are much more flexible then pure REST APIs (of which I see very little) because everybody forgets about HATEOS.
Is this only for very large tables?
Because we have logging that nobody looks at after a month of three, but we have to keep them for five years.
In a historical context:
- the Kernel is essentially MUMPS
- ECP (DCP), the Cache Object model (NextGen) and the concept of Namespaces, Databases and Mappings came originally from DataTree
'Beating' Oracle/ SQLServer et al, is piece of cake for IRIS.
What I am more worried about is 'new' technologies such as "Eventual Consistent" synchronization on large clusters.
I think IRIS could do more on clustering techniques.
Does it work in a mirror constellation?
And there, my friend, we differ completely. ;-)
"someone made the decision to return a status value from methods to indicate success/failure."
A brilliant idea! (Joe D. ?)
In my code I don't want to catch anything, I want to know if a certain method/function did what it supposed to do and if not: report tat to me in a polite fashion (%Status).
It is an interesting exercise, but what is the point of it ?
We've upgraded the (mirrored !) dataservers first, and then one by one the application servers on a live system (200 msg/s) without any issues
We needed to upgrade the RHEL too, so we've created the VM's new, installed IRIS and application.
> messages seems not to purge correctly
That might be if you use:
Property Text as %Stream.GlobalCharacter (or other global based streams)
And then in code: Set Object.Text=PointerToAnotherStream
The original Global node for the property stream gets 'orphaned', it is not referenced by any object and won't be purged (or garbage collected) if the object is deleted or gets out of scope.
The correct way is to use Do Object.Property.CopyFrom(PointerToAnotherStream)
I've had the privilege of working with John at George James. Besides being just a nice bloke, he's a genius.
Although the %Close method doesn't do anything, there is a useful %OnClose callback, where you can do some cleanup if needed, such killing a temporary global.
According to RFC 9110 (HTTP Semantics), only the scheme and the host are case-insensitive