Thanks, John!

Your feedback is filed here.

Thanks, Rob!

Introduced your issue here. Please share more requests and feedback there

Hi Elize!

It's in releases

+1 to Alexander. 

And I propose the new Warning rule for this:

Check for if SQLCODE after every &SQL() before the next &SQL() or before the end of the method.

Hi Oliver!

Could you please mark your answer as accepted? Thanks!

Goran, please mark your answer as accepted - to let the question to be visible as closed and not appear in the "No accepted answer" filter. Thank you!

Aha. You use Cache Studio Evaluation for development. Still have a question: why your employer doesn't give you the full version on Ubuntu which could be downloaded from WRC? 

On the other hand, you don't need a cloud to develop on IRIS Community Edition.  Check @Dmitry Maslennikov recent article. He develops locally on IRIS CE in docker using VSCode.

Hi Cole!

I don't have the answer on your question but why would you need Caché Free Evaluation on Ubuntu when you have the IRIS Community Edtion available on any of AWS, Google or Azure as a container?

I mean if you wanna try Caché today I'd recommend trying IRIS on public clouds or on InterSystems Labs and Quick Starts.

Issue is filed

You can contact me directly (my email is in my profile)) if you want to take this offline.

Hi, Rich! Email is private information - nobody sees your email, except you. But I connect you both if you want.

There is a request for PM in DC, vote for it if needed.

Or maybe we need to introduce Slack for DC.

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?

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 :)

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.

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.