Without wanting to intensify the war, shared variables are in fact a very powerful things and there are some very specific cases where shared variables can have very positive side affects, like improved performance.
Personally I am very much against using shared variables, but there are always trade-offs to be considered - Performance vs. Theoretical Design/Maintainability/etc. Saying "never" to shared variables is similar to saying "never" to denormalised data and we all know that there are some very specific cases where we might need to denormalise.
Do you have benchmarks to prove that they have measurable performance advantages? Are these even meaningful?
At the very least, it would seem that one would need a run statement in a loop with many iterations and, of course, this would first imply the use of a persistent procedure so that the run is a run of an IP and any fixed parameters were set once outside the loop. Unless that procedure essentially does no work ... which is not a very interesting case ... I find it very difficult to believe that the overhead of the run itself doesn't swamp out the overhead associated with a parameter versus a shared variable. And, of course, if the work done by the procedure is that trivial, why isn't it done in-line.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
Static variables also have their usesMore correctly, I think it is "Static variables getused", but where are they a better solution than asingleton or property object and why?
Static variables also have their uses
More correctly, I think it is "Static variables get
used", but where are they a better solution than a
singleton or property object and why?
And how do you think one can implement a singleton in .Net/Java for instance: right, with a static instance variable In those environments there is no class instance chain you can walk....
Shared variables have uses too.I'd make the same translation here. What is onecircumstance where a shared variable is superior to aparameter ... other than in a version of Progresswhere there were no parameters, which is a sillyexample?
Shared variables have uses too.
I'd make the same translation here. What is one
circumstance where a shared variable is superior to a
parameter ... other than in a version of Progress
where there were no parameters, which is a silly
Let's assume you want to stuff a frequently used object handle somewhere:
- you can walk the object chain all the time, trying to find your instantiated class instance
- or you could check the local new global shared variable
]]>Perhaps we should stop and think about whether ornot the OO kool-aid is really all that it's knockedup to be. OO has a place but it isn't the be all andend all. Tom, we know you are not a believer ...
Perhaps we should stop and think about whether ornot the OO kool-aid is really all that it's knockedup to be. OO has a place but it isn't the be all andend all.
Perhaps we should stop and think about whether or
not the OO kool-aid is really all that it's knocked
up to be. OO has a place but it isn't the be all and
Tom, we know you are not a believer ...
Well now that you've reduced it to a religious question I guess there's no need to be rational
But seriously, OO is an interesting idea that makes some problem domains simpler. But it is hardly the end all and be all of programming paradigms (oops! I'm repeating myself...). Nor is it a silver bullet. Brooks proved that there are none of those to be had 20 years ago.
Or, you can put the value in
an SP or singleton object designed to provide such values and
simply retrieve it as necessary. Doing so makes it clear where it
is set and where it is used.
You have no argument that it is not a silver bullet. Did I not indicate that it is very possible to write bad OO code?
My question is that you seem to be suggesting that OO is good for some problem domains and that something else is better for other problem domains. What is that something else that is better? For what domains is it better? Do any of these relate to a domain where one would be writing ABL code of any form?
It is easy to be dismissive ... but it would be more useful to be clear about what exceptions or qualifications you are making.
I have yet to find a problem domain that I care about where OO is, IMHO, clearly "better".
Although I suspect that if I cared more I might find that OO might be better when writing complex GUIs. Then again I think that complex GUIs are probably a mistake in the first place.
There are a few areas where OO might be worth giving consideration to if the Progress implementation goes in good directions (such as the excellent decision to implement simple accessor syntax). But right now I cannot see any overwhelming advantage to be had. It's a nice check off on the marketing side though.
Or, you can put the value in an SP or singletonobject designed
Or, you can put the value in an SP or singleton
But how are you going to find this singleton object when:
- there is no "static" specifier in the OO4GL (there is no "METHOD PUBLIC STATIC ..." nor a "STATIC CLASS ..." as far as I know)
- and you don't want to new up a locator object every time to locate the "Singleton"-instance in the class instance-chain?
Perhaps that comes of writing OO
with public data members! Or, maybe it comes of having not
really tried ... One would have thought that I was the one old
enough to be a dinosaur, but I guess age isn't everything.
But how are you going to find this singletonobjecthttp://www.oehive.org/PseudoSingleton
But how are you going to find this singleton
Come on, be a sports and read all the requirements I wrote "don't want ... to locate ..in the class instance-chain". Your context class needs to be instantiated before it can find the "implementation object" by walking the object chain. So you asked for an example to streamline code: you gave the example yourself...
"Don't want" is not a requirement I take very seriously. It strikes me as a way of being presented with a solution and then denying it by defining it out of existence.
What I like about this pseudo-singleton approach is that it is usable as of 10.1A, but when we get true singletons later, one can simply collapse the action code into the finder and all the rest of the code is likely to remain the same. Yes, it is a workaround, but it is a workaround that works!
"Don't want" is not a requirement I take veryseriously.
"Don't want" is not a requirement I take very
"Don't want" means: I know the another way of doing it.
What I like about this pseudo-singleton approach isthat it is usable as of 10.1A, but when we get truesingletons later, one can simply collapse the actioncode into the finder and all the rest of the code islikely to remain the same.
What I like about this pseudo-singleton approach is
that it is usable as of 10.1A, but when we get true
singletons later, one can simply collapse the action
code into the finder and all the rest of the code is
likely to remain the same.
That's not true, since you have instantiated and deleted this context object all over your code! With a true singleton, you don't have to instantiate the context class, but you would provide a "LoginContext.Current" property.
Yes, it is a workaround,but it is a workaround that works!
Yes, it is a workaround,
but it is a workaround that works!
Accessing a new global variable that's tucked away somewhere is also a workaround that works....
it provides no upgrade path to a better implementation in the
future when it becomes available and in the meantime it provides a
bad example of violating encapsulation.