Re: Public variables - when?
From: gerry (germ_at_hotmail.com)
Date: 03/10/05
- Next message: Bernie Beattie: "Weird problem caused by order of event firing?"
- Previous message: Andrew Howell: "Unknown xxxx - Undefined"
- In reply to: Eugene Vital: "Re: Public variables - when?"
- Next in thread: Tim Witort: "Re: Public variables - when?"
- Reply: Tim Witort: "Re: Public variables - when?"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 10 Mar 2005 08:02:28 -0500
My last comment on this , what I consider , non-issue.
I really don't have any opinion on the use of global's one way or the other.
I tend to have a single application or environmet object declared globally ,
and I have also used the mention global variables for reports. If you don't
like it , don't do it - if you do , do. Spouting you zealous views so
vehemently for the world to see is not a pretty sight.
To talk about strict OOP within VFP is a ridiculous argument.
VFP by nature is not OOP , it may support OOP but it isn't OOP itself - if
it is , then to what class does the STRCONV() method belong ? or the
TRANSORM() method ? ....
further comments inline
"Eugene Vital" <dontwantany@news.com> wrote in message
news:O90KKBQJFHA.2736@TK2MSFTNGP09.phx.gbl...
> Tim Witort wrote:
> > And _SCREEN and _VFP are other global variables. Making your
> > application object a property of another global variable is
> > a ridiculous action whose only purpose seems to be servicing
> > your "global-phobia." You just add more complexity to your
> > application yet are still dealing with global variables.
> > If you question whether _VFP and _SCREEN are global variables,
> > take a look at the help file - it is quite clear that they are.
> >
> It isn't a phobia.
hmm - sounds like it to me.
>
> What complexity?
> hmm
>
> goApp.Usrername
> .vs.
> this.oApp.Username
this , exactly which this are we now referring to ?
>
>
> VFP has varaibles that are available to me, I just use them. Why create
> yet another global variable?
> >
> >> Ever heard of a Singlton Pattern?
> >
> >
> > Yes. It's a design pattern all about having just one global
> > instance of each of your classes. Do you favor or
> > oppose it? It implies that global variables are a necessary
> > thing.
> >
>
>
> Nope, has nothing to do with global variables.
>
> If I ask my application classfactory for an object reference it know if
> it is a single instance object and just returns a reference to an
> existing one if one exists, otherwise it creates it and can store a
> reference to it in a member property.
>
noticing the total lack of static class methods in VFP's OOP implementation
, where exactly does this class factory reside ? A globally available
procedure you say ? or perhaps a piece of reused code that checks for the
existance of an application object as a property of some other globally
available object ? damn - there is that anti-oop global word again.
>
>
>
> >
> >>>Public variables to have their place.
> >>
> >> Maybe in a VB app they do but not in VFP ;)
> >>
> >>
> >> If you are still thinking Global variables then you need to
> >> revisit OOP
> >>design. (IMHO) :)
> >
> >
> > With all due respect. You don't seem to know what you're
> > talking about. OOP relies more heavily on global variables
> > than procedural coding.
>
> With all due respect it is you who doesn't seem to know what your
> talking about. I haven't programmed a global variable since VFP3 came
> out circa 1995.
so ?
>
>
> In case you didn't know it, objects
> > (instances of classes) that are visible to the entire application
> > are global variables.
>
> You only need ONE and ONLY one.
hmmm , vfp itself seems to think you need more than one - this thread has
been mentioning two of them from the very start _VFP & _screen. If you look
in the help under "System Variablesin Visual Foxpro" and you sill see a list
of 40 or so system variables which are defined as : "System variables are
built-in variables that Visual FoxPro creates and maintains automatically.
They are PUBLIC by default"
notice the functional encapsulation between these 2 objects, I think that
you would be hard to put to find any OOP proponent that aspouse the virtues
of creating anything more than a single purpose class whos purpose is to be
one all encompassing global object that is all things to all 'people' (?)
>
> Procedural programming can more easily
> > avoid globals since universally used code can simply be
> > executed via a function call.
>
> not even close.
huh - i would say dead on the mark.
>
> In an OO system, the code is
> > in methods. To call a method, you need an instance of the
> > object (a variable) that implements the method. So, in order
> > for this method to be universally available, the object
> > must be persistent and global.
> >
> Your way off base here man, when I declare a variable as LOCAL it is
> local to that method, when the method ends the variable is released.
talk about off base , how did method variables and their scope enter into
this ?
Tim's statement is 100% accurate. Using OOP, the only way to invoke a
universal method is to have access to a universal object.
>
> Again, there need only be one Global.
ok , so after all that - you do agree that global variables/objects are
useful ?
- Next message: Bernie Beattie: "Weird problem caused by order of event firing?"
- Previous message: Andrew Howell: "Unknown xxxx - Undefined"
- In reply to: Eugene Vital: "Re: Public variables - when?"
- Next in thread: Tim Witort: "Re: Public variables - when?"
- Reply: Tim Witort: "Re: Public variables - when?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
