not sure why barney has used my, but I will quite often break up the
variables into diff structs, just because it seems tidy to me. e.g.
variables.cfg
variables.obj
variables.qry
so i might even have:
variables.cfg.db.dsn
variables.cfg.db.dbtype
-Original Message-
From: [EMAIL
I like using an instance structure sometimes to seperate out the instance
variables from anything else that may be in the variables scope. It can make
it easy to grab a memento of the object's state, for example
getMemento() {
return variables.instance ;
}
-Original Message-
From:
On 9/9/05, Nando [EMAIL PROTECTED] wrote:
I like using an instance structure sometimes to seperate out the instance
variables from anything else that may be in the variables scope.
Can you give an example of anything else?
Patrick
--
Patrick McElhaney
704.560.9117
On 9/9/05, Patrick McElhaney [EMAIL PROTECTED] wrote:
On 9/9/05, Nando [EMAIL PROTECTED] wrote:
I like using an instance structure sometimes to seperate out the instance
variables from anything else that may be in the variables scope.
Can you give an example of anything else?
Sure. I
If you dump VARIABLES you will see that it contains ALL of the methods
and the THIS scope -- for me, that's the main reason (other than
readability of the code) to use a separate virtual scope (I like
instance, but same idea as my) for instance state data.
Patrick McElhaney wrote:
On
Yes, the variables scope has all sorts of garbage in it (not really
garbage, it is stuff the CFC uses to work, but it is not really
instance data). If you dump the variables scope inside a CFC you will
see all the dirty laundry. Using variables.instance makes it far
easier to get JUST the instance
