Global Variables are bad*, but what about Global objects

Global Variables are bad*, but what about Global objects

Post by ds6.. » Tue, 06 Jun 1995 04:00:00



We are attempting to keep our project as OO as we can.  When the following
question came up.

What are the technical and non-technical issues if we make user objects global
(i.e. error handlers, external API object, etc...) or should we create the
object at the application or MDI frame level and fully qualify the name?

Examples:
**** Global Object ****
Object.function()

**** Fully Qualified  at the Application Level ****
Application.object.function()

**** Fully Qualified  at the Frame Level ****
MDIFrame.Object.Function()

We do not have an abundance of reason to place object at any one of the three
different level so I decided to open this up to this group.

Any enlightenment into the internal of PowerBuilder is deeply appreciated

* This is the opinion of the author and the intent is to discuss global objects
not bash global variables.

 
 
 

Global Variables are bad*, but what about Global objects

Post by Roger Snowd » Tue, 06 Jun 1995 04:00:00


: We are attempting to keep our project as OO as we can.  When the following
: question came up.

: What are the technical and non-technical issues if we make user objects global
: (i.e. error handlers, external API object, etc...) or should we create the
: object at the application or MDI frame level and fully qualify the name?

Truly, this opens a real can of worms.  We are all, to some extent, both
purists and pragmatists on this and other issues.  But, without
reservation, I would suggest that you eliminate the notion that 'global
variables are bad'.  If they apply globally, then they are appropriate.  
Don't worry about wrapping them up in a function to make them look more
like an object.  They are what they are.

The solutions you seek will be found through analysis.  When you get sick
of analyzing, make a decision and build a product.

Good luck!

Roger


 
 
 

Global Variables are bad*, but what about Global objects

Post by Grant Gardn » Wed, 07 Jun 1995 04:00:00



Quote:

>We are attempting to keep our project as OO as we can.  When the
following
>question came up.

>What are the technical and non-technical issues if we make user objects
global
>(i.e. error handlers, external API object, etc...) or should we create
the
>object at the application or MDI frame level and fully qualify the name?

>Examples:
>**** Global Object ****
>Object.function()

>**** Fully Qualified  at the Application Level ****
>Application.object.function()

>**** Fully Qualified  at the Frame Level ****
>MDIFrame.Object.Function()

>We do not have an abundance of reason to place object at any one of the
three
>different level so I decided to open this up to this group.

>Any enlightenment into the internal of PowerBuilder is deeply
appreciated

>* This is the opinion of the author and the intent is to discuss global
objects
>not bash global variables.

Forgive me if I'm stupid but I have never understood
the argument against globals variables/objects.
If an object (be it a simple integer, or a complex object) requires
global scope then so be it.

If an instance of an object gets global scope
by being attached to something that also has global scope (eg Application
or MdiFrame) then as far as I'm concerned it *IS* a global variable.

That said there are reasons for not having lots of global variables
in the direct powerbuilder sense.
(ie declared in the "Declare Global Variables" painter).

If multiple developers each have their own copy of the application object
(for library list purposes), then every time a new global is added each
developer has to update their copy of the application object.
This actually applies to anything attached to the application, hence
anything attached to the application level.
Also any changes to the application object (including new global
variables) mean that a new exe has to be compiled. Avoiding changes
to the application can mean that changes can be distributed through
new PBD's only.

Using the Mdi_frame in some kind of way to avoid using a global
definition so as to say
"I have no global variables" is simply a cop-out and breaks the
OO principles of encapsulation which is what you are really trying
to achieve.                    

One way that is reasonably nice, is to have a single global variable
which is a container object for all your other objects that require
global scope. (eg in the Declare Global Variables window...)

u_global_container g_globals

Where u_global_container is a user object with public instance variables
for all your other global objects and IFF necessary simple variables.
(BTW This can include the mdi_frame!)
so all references to globals are.

g_global.object.function()

Where a visual global object is required (eg window or datawindow, for
storing static data etc..) this can be done as a hidden window or
userobject on the mdiframe.
eg OpenSheet(g_global.hiddensheet,g_global.mdi_frame).

Good luck,
        Grant.

PS. I have precisely zero qualifications for saying any of the above.
--
________________________________________________________
Grant Gardner

The views expressed here are mine and most likely no-one else's.
Specifically they do not necessarily represent my employer.
________________________________________________________

 
 
 

Global Variables are bad*, but what about Global objects

Post by Tim Jarre » Thu, 08 Jun 1995 04:00:00




>>What are the technical and non-technical issues if we make user objects
>>global (i.e. error handlers, external API object, etc...)
>Forgive me if I'm stupid but I have never understood
>the argument against globals variables/objects.
>If an object (be it a simple integer, or a complex object) requires
>global scope then so be it.

Well, the argument against making variables global is simple--if a
variable is globally available, it's globally changable as well.  By
restricting access to a variable through object-oriented techniques
(encapsulation, data hiding), you minimize the number of ways that clever
developers can change a global variable and really*up the rest of
the application.  (If you don't think this is a problem, you've probably
never worked on a project with more than one other developer.)

Global objects, on the other hand...  If an object is truly globally
applicable, make it global.  The nice thing about PB 4.0 is that the
default global objects (SQLCA, the Error and Message objects) are
inheritable and you can specify objects of the same type as the default
objects.  This enables you, for example, to inherit from the Error object,
make all your error-handling methods public functions on your Error object
descendant (so that developers and code maintainers know where to find
them), and specify your hot-rodded object as the default Error object for
the application.

Mostly, I think, it's a question of preference about making other objects
global.  If it works for you, great.

--

"And one day you get that letter you've been waiting for forever. And
 everything it says is true.  And then in the last line it says:
 Burn this."  --Laurie Anderson, "Same Time Tomorrow"

 
 
 

Global Variables are bad*, but what about Global objects

Post by Kjetil Kilha » Fri, 09 Jun 1995 04:00:00


Followup-To:


Organization: Telenor AS, IT-avdelingen
Subject: Re: Global Variables are bad*, but what about Global objects
Keywords:


((( cut )))
|> >Forgive me if I'm stupid but I have never understood
|> >the argument against globals variables/objects.
|> >If an object (be it a simple integer, or a complex object) requires
|> >global scope then so be it.
|>
|> Well, the argument against making variables global is simple--if a
|> variable is globally available, it's globally changable as well.  By
|> restricting access to a variable through object-oriented techniques
|> (encapsulation, data hiding), you minimize the number of ways that clever
|> developers can change a global variable and really*up the rest of
|> the application.  (If you don't think this is a problem, you've probably
|> never worked on a project with more than one other developer.)
((( cut )))
Another problem is that it's so easy to accidentally use these global variables in scripts on objects that could later be basis for another application and then you have to have those same global variables there or change a lot of scripts
-----------------------------------------------------------------------------
Kjetil Kilhavn, archer, member of Team OS/2
(This message kindly brought to you by Telenor, the telecom company in Norway)

 
 
 

Global Variables are bad*, but what about Global objects

Post by russe.. » Sat, 10 Jun 1995 04:00:00



>purists and pragmatists on this and other issues.  But, without
>reservation, I would suggest that you eliminate the notion that 'global
>variables are bad'.  If they apply globally, then they are appropriate.  

I disagree on this issue.  One should be very careful when declaring global
variables.  The problem with global variables is their effect on performance.
When a global variable is declared, PB will allocate a piece of memory for
that variable.  This can make apps both slow and resource hungry.

I once so an application that contained 4 or 5 unbounded arrays declared as
globals.  When we used other methods to eliminate these arrays, performance
increased dramatically.

My suggestion for something like error-handling is to think of the scope
in terms of the object.  Then create a user-object and use that in place
of PB's objects.

For example,  most DB errors will be flagged in a dw control.  I create
a visual user-object of type DW control.   In that user-object I put all
error handling that occurs on the DW control level.  I then use this new
DW object in place of the PB dw control.

In essence, try to break everything down to its control level.  Create a
series of controls (/uo's) that suit your needs. When you place these
uo's they become descendants of that original object and can be modified
accordingly.

Hope it helps,
Russell Lowell
RCG Information Technology