Think about it a little ...
If you insist...
... if you have a shared variable or a global shared, you really have only good discipline to be sure that it contains the intended value. If some day you find the wrong value, e.g., it shows up blank in a place where you expect it to be set, you have no clue where the problem exists because it could be anywhere that the variable is accessed.
So far so good... but not really very compelling.
Make it a parameter and you know exactly where it came from and can trace back until you find the error.
It being a parameter doesn't help you at all with the enforcement of valid values or the tracing aspect. It tells you
nothing about where or when any value was assigned. Nor does it help you ensure that it is valid.
Put it in a static object or superprocedure and again you will know exactly where and when and how it gets its value while retaining the lighter signature of the call.
"Lighter signature"? Where? As compared to what?
How is it that merely making something an object or putting it in a super-procedure lets me know exactly when and how something got a particular value?
It doesn't.
The only indisputable advantage to making it an object is that you can enforce rules about it's value (for instance, perhaps you have a rule that a number can only be an odd number). With variables (shared or otherwise) and parameters the only enforceable rules are those imposed by the data type. Even if you need such an advantage you don't get it for free -- you still have to code it. But at least you know that it will actually be enforced if you go to the trouble.
I suppose too that you could, in theory anyway, introduce some tracing features into an object and keep track of who has been fiddling with it for traceability purposes. But you don't get that simply by creating an object either.
NEW GLOBAL SHARED is, essentially, a static object without any special rules. If that's all you need then why mess around?
That was a somewhat rhetorical question and, I think, there are 2 serious answers:
1) What you need today isn't always what you need tomorrow -- if your requirements change and you someday need to add tracing capabilities or want to enforce rules about the value of xyzzy you have a nice central location to do that.
2) You cannot use SHARED stuff inside classes. So if you start to mess around with any of the .NET interface stuff or if you just like OO in general you're going to have to cross this bridge. Plus more and more of the interesting code that PSC provides is starting to be delivered as OO code. There's a whole new data dictionary API for instance. And it's OO. So like or not OO is going to be increasingly in our lives and we may as well come to terms with it.
Finally, it is actually very easy to create a static object that acts like a global shared variable:
Code:
/* gsv.cls
*/
using Progress.Lang.*.
class lib.gsv:
define public static property xyzzy as character get. set.
end class.
And in any program where you want to use "xyzzy":
Code:
using lib.gsv.
/* ... */
gsv:xyzzy = "pflugh".
(Notice that you don't have to "NEW gsv" anywhere...)
This is actually less typing than "define new shared variable xyzzy as character no-undo." The only thing that you lose is compatibility with v9 and earlier. (Not that anyone should be enabling the perpetuation of ancient, obsolete and unsupported releases...)