Can someone remind me, why variables.instance?

[Henry]

Can someone remind me, why store instance variables in
variables.instance? Where are the benefits?

Thanks,
Henry Ho

[Peter Bell]

So the names of the instance variables don't potentially conflict with
method names, and so you have a single struct you can operate on where
all of the keys are simple variables, not methods or anything else.

Best Wishes,
Peter

[Jared Rypka-Hauer]

It keeps your instance data disentangled with private functions and
the variable's scope handle on THIS, so it makes it easy to do things
like <cfset MyCfc.setMemento(structOfData)> and load a whole
instance's instance data at once.

It's easier to dump data without dumping funcitons. :)

Beyond that not much.

J

[Jared Rypka-Hauer]

Hrm... so you keep nested structs and CFC instances out of
variables.instance??

That's not how Transfer works, for example, because Transfer's
"memento" is actually a copy of the instance data for an object and
all it's composites. So if you have User.getAddressArray(),
User.getRolesArray() and User.getEmployer(), if you call
User.getMemento() you'll actually have at least 3 keys with complex
data.

J

[Peter Bell]

Yeah, sorry I misspoke. You're right - the instances contains
properties which could be objects, arrays, structs, etc. But I'm
sitting in Ben Nadels jQuery preso and trying to pay attention!

[Henry]

On Feb 10, 3:29 pm, Jared Rypka-Hauer <armchairde...@gmail.com> wrote:

> It's easier to dump data without dumping funcitons. :)

Charlie's presentation just reminded me that <cfdump showUDFs = "yes|
no"> is added to CF8. And that's why I ask this question to see if
this new cfdump attribute alone can justify not using
variables.instance anymore. :)


Henry Ho

[Henry]

btw, here's the presentation:

ColdFusion 8 Best Kept Secrets @ Max NA 2008
http://tv.adobe.com/#vi+f15384v1088


Henry Ho

[Jared Rypka-Hauer]

Well then stop sending email, you crazyman! ;)

J

[Oscar Arevalo]

Even with that addition to cfdump I find that putting all my instance variables under one struct is always helpful since it makes it easier to look at the "state" of the object at any given time, as well as making it easier to set/get memento when needed. In the same token I sometimes find useful to use a different struct at the variables level for constants or values that you dont expect to change or be dynamic but still want to declare in just one place. i.e. variables.constants = {PI: 3.14, G : 9.8 } or something like that.

--
Oscar Arevalo
http://www.oscararevalo.com

[Barney Boisvert]

While that's a benefit, it doesn't protect you from naming collisions
between fields and methods.

I like having a separate struct (I always use 'my' - an old habit) for
two reasons. First, I put instance state into the 'my' scope, and I
put transient state (constants, for example) into the variables scope
directly. This always gives access to just the instance state.
Second, it helps when reading, the 'my' prefix clearly indicates that
the variable in question is NOT a local var or an argument, it's an
instance variable. I endeavour to always use a 'variables' prefix for
the variables scope, a 'my' or 'variables.my' prefix for the 'my'
scope, and then the only unscoped references are either local or query
vars.

cheers,
barneyb

On Tue, Feb 10, 2009 at 3:48 PM, Henry <henry...@gmail.com> wrote:
>

--
Barney Boisvert
bboi...@gmail.com
http://www.barneyb.com/