Nope.
The
"unnamed scope" - by which I guess you mean the scope in which VARed variables
go in - are local to a function instance; not really in a similar vein to
"this-scoped" variables @ all, as they have nothing to do with the state of an
object: they get cleaned up as soon as the function calling them
finishes.
You
should use the VARIABLES scope of an object to store "private" data (well: more
like "protected", I think... I forget my OO jargon). Accessible internally
to the instance of the object, but not to the code instantiating the object in
the first place.
Having
said that, there's no true way of securing even those variables, as there's
nothing to stop someone instantiating the CFC and then inserting their own
functions into it, which in turn access the internal variables scope. This
sucks a bit.
Adam Cameron
Senior Application Developer
Straker
Interactive
Ph: +64 9 3605034
Fx: +64 9 3605870
Email:
[EMAIL PROTECTED]
--------Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Taco Fleur
Sent: Tuesday, 29 June 2004 10:58 a.m.
To: CFAussie Mailing List
Subject: [cfaussie] thisSo the this. structure is available outside CFCs and can be directly accessed, and the closed you get to protecting the variables is by using the un named scope, which is basically a work-around. Is it not better to keep using the this scope as intended and hope that the way it functions will change in the next release of ColdFusion?
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
Register now for the 3rd National Conference on Tourism Futures, being held in Townsville, North Queensland 4-7 August - www.tq.com.au/tfconf
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
