One's private parts and global 'Var' 1

[LucieLastic]

hi All

I've noticed in the past that some programmers (I've worked with) use a global VAR in the Implementation part of the unit. I never do this, and always use my Private, public parts etc and properties where appropriate.

What's the advantage of using this global Var and is it better, or worse than using the unit's sections. Or..is it for units that contain more than 1 class which share the same variable? I never have this as I tend to keep different classes to different units - not sure if this is good but my own preference really.

Just a thought I'd be mulling over.

lou

 

[svanels]

I use them sometimes, mostly logical variables for defining a flag or state of a process ex:

if ok_to_proceed then

Regards S. van Els
SAvanEls@cq-link.sr

 

[delphiman]

I protect my own "private parts" with a cricketer's "ball box"! )

(Sorry! I couldn't resist it!)

 

[EricDraven]

The main difference is that a global variable can be directly accessed by any procedure on that form. A private variable declared in a procedure is referencable only by that procedure. A global variable could be referenced by several different procedures run in a sequence.

 

[LucieLastic]

hi Eric

What I mean by Private, is a variable declared in the private section of the unit/class header, rather than being local to one procedure, so it is visible to all procedures in the said class. By global, I mean it is declared at the top of the implementation section of the unit.

It's okay now, this thread was started has it was one of the those little thoughts that I had wondered about and wanted to know how people use the Var in this way.

lou

 

[sggaunt]

Hi Weev
I suppose that we shoundnt use any 'Global' variables at all (module scope or otherwise), but this can cause a headache in an event driven language like Delhi.
I use some modules containing maths and string utilities that arn't typed at all, this means I can use these functions in any applications without having to muck about working out the proper paths into the module.
Some people who have been brought up purerly OOP will be throughing their hands in the air no doubt?
I belive that (dispite what I got told at Uni) Programming is Part science part art and having a 'Style' is not a bad thing. So do what you like to get the results you want.

I used to reckon I could tell a Jeff Minter game just by looking at the Dissassembly.

Steve

 

[Oppenhiemer]

Hi -

I can echo what sggaunt says about global vars. In effect - you should not have any. In effect they break object containment in OO terms.

They have to be used with care in any case, as they have a longer life than local (or private) variables and therefore can interfer with the behaviour of the program as a whole.

When u use local or private variables, their values are transient and these are re-set when the program moves out of scope of the procedure/function in question.

So there are 2 objections there, one stemming from the principles of OO technology; and one from a general need to control the behaviour of variables within the program.

The thing is, lifes too short ;-). I guess much depends on your needs. For most of us - time is an issue and if using em means less typing - so much the better ;-). I use em myself so..

Cheers..

Opp.

 

[svanels]

I object to the opinion that global variables shouldn't be used, in fact they are used exaustively in Delphi, only we are not aware of it. Ever heard of DataModule?
Delphi documentation recommends to put your non-visual components in a Datamodule, things like queries, tables, image lists, action lists, pop-up menus.
Your own made global variables, procedures and functions can be placed in the same DataModule.

Regards

S. van Els
SAvanEls@cq-link.sr

 

[Icarus70]

Regarding the DataModule:

Technically, when you put your non-visual components in the DataModule, they are encapsulated within the DataModule itself -- so they are not strictly speaking "global variables". You must reference them through the DataModule object.

Having picked my nit, let me go on to say that I agree, global variables/procedures/functions are well placed in the DataModule unit (at the Unit level, not the Class level), since it's quite likely you will include the DataModule unit in your USES clause for most of your project anyhow.

I also use global vars for status flags (used to use typed constants, but D6 doesn't like that any more!) Other than that, I try to avoid using them for the OO reasons mentioned already. It's really a judgement call as to how important it is for any given project to stick to the "approved" techniques -- but for projects of any substantial size where ongoing maintenance is going to be an issue, I vote for taking a little longer to do it right the first time and avoid the potential conflicts/problems down the road.

-- David

 

[BobbaFet]

This thread just proofs that programming is an artform BobbaFet

Everyone has a right to my opinion.
E-mail me at caswegkamp@hotmail.com

http://cwcon.50megs.com/