10.1A Progress 4GL Handbook, by John Sadd and Shared Variables - Forum - OpenEdge Development - Progress Community

10.1A Progress 4GL Handbook, by John Sadd and Shared Variables

 Forum

10.1A Progress 4GL Handbook, by John Sadd and Shared Variables

  • 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 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 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

    example?

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

    end all.

    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.

    --
    Tom Bascom
    tom@wss.com

  • 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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • 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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • 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.

    --
    Tom Bascom
    tom@wss.com

  • Or, you can put the value in an SP or singleton

    object designed

    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?

  • http://www.oehive.org/PseudoSingleton

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • 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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • But how are you going to find this singleton

    object

    http://www.oehive.org/PseudoSingleton

    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!

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • "Don't want" is not a requirement I take very

    seriously.

    "Don't want" means: I know the another way of doing it.

    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!

    Accessing a new global variable that's tucked away somewhere is also a workaround that works....

  • Works, but

    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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com