Right... This is for moving from say... the DB to the screen via a
single method call i.e. thisUser.get(12)
<cfoutput>thisUser.fname</cfoutput>
OR, to be a lot more verbose:
In the case of:
<cfset thisUser = createObject("component","user.cfc").init(12)>
<cfoutput>#thisUser.fName# #thisUser.lName#</cfoutput>
where inside the CFC this.fName = query.fname and this.fName =
query.lName and init(12) is passing the table's pkey value (possibly a
URL variable) of 12 into the arguments and on to the where clause of a
query.
I've got that THIS thing down fine. I guess it's the difference
between private instance data and function-private variables that has
me a little puzzled.
And even at that, I can see why one would choose to use function
private variables for somethings, especially things like loop counters
that need to be trashed as soon as their use is over, or for security,
trashing a piece of private data that shouldn't be kept in memory
"just in case."
Oi, I just realized something else... something like a query that gets
data to populate a CFC needs to be var'd or it'll stay resident in
memory until the server destroys it. So I can see the need to conserve
memory by the judicious use of var...
But still, what does all this have to do with the var keyword and
threadsafe CFCs??
Laterz, all!
J
--
Continuum Media Group LLC
Burnsville, MN 55337
http://www.web-relevant.com
On Fri, 24 Dec 2004 17:54:04 -0800, Sean Corfield
<[EMAIL PROTECTED]> wrote:
> On Fri, 24 Dec 2004 19:19:29 -0600, Jared Rypka-Hauer - CMG, LLC
> <[EMAIL PROTECTED]> wrote:
> > Perhaps I should begin my question with my perhaps-incorrect
> > understanding of instances. I have always understood an "instance" to
> > be a unique, individual memory-resident copy of an object that
> > contains methods and properties, or functions and attributes, or
> > whatever they be called in your current universe. An "instance" of an
> > "object" would, then, be the result of a call to the object's codebase
> > from within an existing thread, and it's constructor would fire as
> > soon as the CFOBJECT or createObject executed.
>
> Yup, that's pretty close although CFCs don't really have constructors.
> When you create an instance, CF will execute the "pseudo-constructor",
> the code that is inside <cfcomponent> but outside of any <cffunction>
> tag.
>
> A lot of people have adopted the practice of defining a method called
> "init" to act as the constructor (so that the same syntax that calls a
> Java object's constructor with arguments can be used for CFCs).
>
> <!--- constructor for MyObject.cfc --->
> <cffunction name="init" returntype="MyObject" access="public" output="false">
> ... arguments ...
> ... initialize the instance ...
> <cfreturn this />
> </cffunction>
>
> Then you can construct and initialize in one statement:
>
> <cfset obj = createObject("component","MyObject").init(args) />
>
> (change "component" to "java" and the same syntax will work for MyObject.java)
>
> > I've always assumed that an instance would be intrinsically
> > thread-safe if the underlying engine was also thread-safe.
>
> It depends where you store the instance. If you store the instance in
> a per-request variable, it'll be thread-safe. If you store it in a
> shared scope, it'll be subject to the same issues as any other shared
> scope variable (assuming the instance stores state information in
> "this" scope or "variables" scope).
>
> > And, in that case, it's
> > THIS scope would be available to all methods within the instance
>
> And to everything outside the object. "this" scope is public,
> "variables" scope is protected (in Java-speak).
>
> > whatever non-scoped var you create within a method would be
> > function-local by default?
>
> Function-local requires use of the "var" keyword:
>
> <cfset var x = "I'm local" />
> <cfset y = "I'm in 'variables' scope - protected instance data" />
>
> "var" is used at the top of the function to declare a function-local
> variable. The second statement (the assignment to "y") is equivalent
> to:
>
> <cfset variables.y = "I'm in 'variables' scope - protected instance data" />
>
> > Until now, I've been using this THIS scope A LOT, not VARing any of my
> > method variables, and wrapping CFLOCKS around calls to methods that
> > would alter the data within a session-scope persistent CFC. Have I
> > been doing this wrong?
>
> Yes. Probably. Using "this" scope is definitely 'wrong' because it's
> public data. If you want variables that are function-local, you need
> to declare them with "var". If you want instance data shared between
> multiple method calls, you should use "variables" scope.
>
> > So, now that I've laid my ignorance out for you all to see, please be
> > gentle? :D
>
> Hope my comments help?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Special thanks to the CF Community Suite Gold Sponsor - CFHosting.net
http://www.cfhosting.net
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188776
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
