OOPhoto: VARIABLES vs. VARIABLES.Instance - When And Why?

seems like what you're really after is a static scope for the dsn, esp when multiple Bra.cfc's are instanciated in a request scope (or similar). well, maybe not for the DSN, but something to share across all instances perehaps.

sure there are work-arounds in CF if you juggle the architecture, but I've been glad I've had static variables in C# classes with some tricky situations, and CF hasn't quite got the same thing.

meh, my 2c

Ok, so now that you have explained how you separate out the variables, can you tell me why?

If you as the writer of the component know the difference between the object's data, what benefit do you get from placing it in a different place? Is that in case you forget later, or do you have some dynamic code you use that programatically uses certain variables based on where they are stored?

why?

I do (or did) something similar to Ben. for me loose keys in VARIABLES scope are plumbing - stuff to keep the component itself going. the instance key is really internal data - important to that instanciation of that component instance.

it all comes down to having sufficent namespaces to park stuff.

BTW, talking about singletons can be a red herring. "there can be only one" is imposed externally from the component's POV. (there is a workaround where you can but) the component shouldn't know or care if it's a singleton.

Ben, those loose VARIABLES keys - the plumbing: that's what I'd like to see for a STATIC scope that is shared across all instances of that component. If they need to change per instance, then they're not plumbing and go into VARIABLES.instance.

meh, my 2c

That reason of yours is not very strong for using VARIABLES.instance, 'cause isn't DSN usually stored in the APPLICATION scope anyway?

However, I do use VARIABLES.instance in my project, just because Illudium PU-36 Code Generator generates the beans for me. At first I didn't know the reason why, but from what I remember, their argument was:

1.) to cfdump only variables you defined, because the VARIABLES scope has some built-in vars added by ColdFusion. I forgot what are those built-in vars, but you can try yourself.

2.) easier to compare/clone an object

However, for cfc that I wrote by hand, I usually don't have any reason strong enough to convince myself using an additional 'instance' scope. I guess I don't like the idea of another java map (hashmap?) look-up.

I'm in agreement with Henry and Barry (as they mentioned briefly), variables.instance is a great way to have a separate "namespace" for your internal class variables.

This can be handy for several reasons including;

- a dump() to easily see your entire class "state"
- separate your class variables vs things like dsn's and composed objects (as you mentioned already)
- obvious clarity in the difference between local method vars and class "instance" vars etc

http://www.chapter31.com/2007/06/14/using-variablesinstance-inside-your-components/

@Henry

meh, personal choice rules, OK?

I understand what Ben is doing and why and have similar thoughts. an extra hashmap lookup, not a bit deal in the scheme of things.

"cause isn't DSN usually stored in the APPLICATION scope anyway?"

IMHO, NEVER. or rather, unless there's special circumstances**, you will NEVER see the guts of any CFC of mine referring to an external scope. I use SERVER scope as much as APPLICATION and more likely or not will pass in an object into the init() for the DSN or a directory for CFFILE or whatever. But more often or not, ColdSpring is a good way to go, and Transfer for ORM work so it can turn into a bit of a moot point.

as I said, I can't see a problem with how Ben is doing it. At least not enough to change.

my 2c

** you gotta know the rules before you can break them

I think I am obligated to remind those who are learning CF to avoid the pitfall of just blindly follow conventions or practices in generals without understanding ultimately what they deliver, or how they'd help you, your team, or your app in the long run.

Challenge every bit of added complexity to CF that might slow down your CF app development. Evaluate the cost & benefits. :)

Another benefit to Railo is that we can scrap all this variables.instance crap because it is a performance hit. It's necessary with CF8, but it is costly.

@Justin - Not sure what you mean there, could you elaborate?

1. Performance hit for a simple 1 level struct? Would this even be a blip on the radar even under heavy load?
2. Part of the benefits of having this 2nd level "key" under variables includes encapsulating specifics of your object, things like properties vs plumbing vs methods etc

Does Railo have implicit "private" variables inside class (cfc) methods or something?

@Michael -

Railo allows you to configure your scopes as you would like so that the "this" scope in CFCs can actually be private rather than public.

Gert did a demo of speed differences between using variables.instance and "this" and it was pretty impressive. So, with Railo, you can have it behave the way ColdFusion behaves, or you can configure it to behave more strictly so that we can use the "this" scope like normal programmers.

I don't know, you'd have to get Gert from team Railo on the horn. I'm sure it has something to do with the underlying Java and perhaps scope checking.

Surely this.address1 vs. variables.instance.address1 must be faster because it's shorter, right? :)

The main reason I use variables.instance.{variable} over variables.{variable} is because of name conflicts with function names and the private scope.

Far from a great example, but if I have a variables.email string set to an email address and a function called email, then I cannot access the email function via variables.email().

@Ben, another good discussion.

I definitely like separating object variables in to different scopes.
A benefit I didn't see mentioned:
- transmitting values between objects/applications/systems.

By separating object variables in to different scopes, I was able to create functions like
struct = getDataVariables() - returns variables.data
and setDataVariables(struct) - set variables.data
(I use the data scope to contain the information an object was design to manipulate)

Example usage:
I have an object that represents a blog entry.
my entryObj contains the entry title, subjects, author, the entry, and other attributes.
I can use entryObj.getDataVariables() to get a struct containing that information.
I can then persist the struct as a JSON or WDDX string (title, author, categories etc),

When a user requests the page, instead of a complex database hit, I can
- create a new entry object
- load the JSON/WDDX string (from a file or db field)
- convert it back to a struct,
- use entryObj.setDataVariables(struct) to populate the new object
- pass the object to the appropriate page renderer (xhtml/flash/wml etc)

I can also send the JSON or WDDX string to a completely different application coded in a different programming language. As long as receiving application can decode JSON or WDDX, it can recreate the struct, and populate an equivalent object in that application.

I think this approach is called the memento pattern.

Or should we as a CF community raise this issue to the CFML Language Advisory Committee, and ask for a better CFML standard?

How about adding another scope other than THIS and VARIABLES that works only with CFC? a new INSTANCE scope, anyone? :)

What do other languages do? Someone mentioned declaring the plumbing vars as Static. I can see that it makes sense most of the time, but does that make sense all the time?

@Justin et al.

Struct access is so fast as to not be worth even thinking about.

Honestly, calling functions costs WAY more. I don't see anyone suggesting not breaking your code up into lots of readable, reusable, functions or objects because its "slow" ?

A lot of this "X is slow" stuff needs to be put to rest.

Using variables.instance or just plain variables has absolutely no measurable performance difference on anyone's code.

I needed to get up near 10000 accesses to get something measurable. variables.instance, variables.bar and instance.bar are all just as "slow". bar without a scope qualifier turns out to be the fastest, but I don't see anyone suggesting never scoping variables for performance.

The three previously mentioned methods are all about 4-6x as slow as unscoped accesses. Using an instance scope has no effect.

To put this in perspective, calling a function that does *nothing* is 11x slower than accessing an unscoped variable, and 2x slower than accessing a scoped one!

Calling createUUID() repeatedly is exponentially slower than accessing a struct member. In my test of 10000 iterations it took 6800x more time than the struct access. (there's probably a sleep in there or something, but the point is that if your objects use this function the instance scope is certainly totally unrelated to your performance hit).

Honestly, this is not the bottleneck in anyone's application. No one is doing 10k struct accesses per request, and even if they were, adding 7ms to a request is nothing when database access takes 50-200ms, and just plain outputting the page takes 20-100ms!

It's far more likely that your application is slow because you tried to be "Object Oriented" and created big arrays of objects instead of an iterator around a Query, or loaded large xml files and didn't cache the result, or any number of architectural things that have nothing to do with the core language.

Design your app right, don't worry about silly language things. Please? :P

(Railo might have different performance characteristics, but if struct access is Railo's bottleneck then something else is terribly wrong.)
(All testing done on CF8.0.1 on a C2D with 4GB of ram on JRun+Java 1.5)

I personally like to use a variables.instance structure. This also raises the question of where to declare your variables struct. If you have a pseudo constructor do you do this:

<cfcomponent>
<cffunction name="init">
<cfset variables.instance = StructNew() />
...
</cffunction>
</cfcomponent>

or

<cfcomponent>
<cfset variables.instance = StructNew() />
<cffunction name="init">
...
</cffunction>
</cfcomponent>

I always use the area after the opening <cfcomponent> tag, and sometimes even use cfparam just to make it clear what's happening.

I really had not thought about separation of static ( write once / read many ) variables from the dynamic variables in components, but it is an interesting idea.

I dislike using the variables scope directly, but setting up a variables.static structure is very appealing.

You could setup onMissingMethod set/get logic to allow multiple read/write to keys in variables.instance and set once/read many logic for keys in variables.static.

@Henry Ho,

"How about adding another scope other than THIS and VARIABLES that works only with CFC? a new INSTANCE scope, anyone? :)"

In a way I agree but in a way I just shrug my shoulders and say "meh". After all, one has to wonder exactly what was going on that they yet again had to have CF blaze new but misguided trails in having THIS be available publicly.

Hum.. interestingly I just asked this question last week because I forgot the reason behind Variables.instance scope.

CFCDev: Can someone remind me, why variables.instance?
http://groups.google.com/group/cfcdev/browse_thread/thread/9f52a824eec12fc1#

As for using This scope, I've found many CFer's actually do not use or never heard of using getter and setters... so they just use This scope... oh well, whatever works, right? :)