AllAccepted answers
Evgeny Shvarov · Mar 14, 2019

So it could be named "Side effects of Quit and Return command with $Increment", right?

As to RETURN, it seems that InterSystems promotes this command nowadays as a more visually clear remedy to exit methods.

We want to promote things which help.

It seems to me that having "return" in ObjectScript we can change the meaning and usage of "quit" as for cycles interruption only?

Not touching "dot syntax" and argumentless "quit" in for what are the cases of using "quit" we have?

Evgeny Shvarov · Mar 13, 2019

Hi Alexey!

Thank you for teaching me COS :)

Didn't even try, you know ;) 

But for those who see your code sample, I, as a Community Manager, must say that dot syntax and "do label" is never a good practice in ObjectScript today. 

And I can't imagine that InterSystems product manager who introduced return in ObjectScript could see it called from dot-level ;)

I think that we have {} in ObjectScript to excuse the dot-syntax usage and do ..Method() for do Label cases. 

The rewritten sample is not functional equivalent of the original one and will return the different result (if correct the syntax error).

This illustrates how dot-syntax could easily obfuscate the logic if you want ;)

My sample was not about "old" syntax vs. "new" one; I just wanted to emphasize that simple substitute "quit" with "return" command either may or may not improve the readability of already existing class/routine, it all depends...

Agree. 

But IMHO for a new ObjectScript code in InterSystems IRIS return value is always more readable than quit value.

And I think in majority cases, where you don't use "dot-syntax" this replacement could be applicable too.  @Eduard Lebedyuk  - is it eligible for your 

Quit: $$$IsError(sc) sc

case? 

And to All: this is not an instruction to action!

This is the discussion and activity to introduce a Developer Community Coding Guidelines Best Practices for InterSystems IRIS ObjectScript. You may use this or may not but it's good to have it.

P.S. I think we need to stop shrinking the levels of the thread in DC engine :)

Evgeny Shvarov · Mar 12, 2019

Nice example, Alexey)

But I wouldn't use either dot-syntax or "do label" in new ObjectScript code.

This could be changed with ObjectScript best practices:

ClassMethod t1() as %Integer 

{ 

 do ..t2(.a,.b) 

  n a,b

  set a=4,b=5
  return $increment(a)*$increment(b)

}

ClassMethod t2(ByRef pA, ByRef pB) as %Integer

{

 set pA=2,pB=3
  return pA*pB

}

Which, IMO, gives you more clear understanding what the code does.

Evgeny Shvarov · Mar 12, 2019

Alexey, I do not argue the difference, between "return" and "quit". There is a difference.

In this case it's a guess that if we check the error and return the value with "quit" it's 100% case that it is a quit from the method, rather then any other use cases of "quit".

So it is "return". @Eduard Lebedyuk ?

Answering your point - IMO "return" is a more readable command to get a direct answer on "What this method returns" question.

Evgeny Shvarov · Mar 11, 2019

Hola Daniel!

Thank you for your explanation! And thank you for a really great tool!

if condition
    do ..something()

I agree, and this is not a good practice - two lines with if.

But nobody does that in ObjectScript. As developers consider spaces in Python so developer follows the nuances of the ObjectScript. And oneliner

if condition do ..something()  

is considered as a readable and convenient way to code ObjectScript.

As well as postconditions on 

quit:$$$ISERR(sc) sc

Daniel!

I suggest to let Developer Community vote for the rules and this will let Community have a general version of adopted ObjectSript coding guidelines along with a general tool - CacheQuality which can so nicely help to control these guidelines.  What do you think?

Evgeny Shvarov · Mar 10, 2019

Don't like post conditions.

And anyway - for this you'll get from CacheQuality:

"Consider using an If statement instead of a postconditional (cachequality:OS0039)"

with description:

"This feature of the language may lead to shorter code overall; however, users unfamiliar with the language may have trouble understanding what this syntax means.

For understandability reasons, it is preferred to use an if statement instead."

;)