It's very important if you are doing any type of recursion. -Adam
On 11/10/05, Nando <[EMAIL PROTECTED]> wrote: > > and > >you HAVE to var scope ALL your variables that are local to your > >cffunctions in order to make them thread safe. > > This is true, but to clarify it, i think it's only a problem if multiple > threads can access your CFC. So if a CFC is instantiated and dies with the > request ... only one thread is ever going to touch it. So where it's really > important is in application scoped CFCs. > > That said, in practice you get into the habit of doing it with all your > functions, so you don't have to consider it carefully in each and every > case. > > Someone correct me if i'm wrong. ;-) > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >Behalf Of Matt Woodward > >Sent: Thursday, November 10, 2005 3:33 PM > >To: [email protected] > >Subject: Re: [CFCDev] Scoping > > > > > >On 11/10/05, Phillip Senn <[EMAIL PROTECTED]> wrote: > >> Well, I'm particularly struggling with the scoping inside of cfcs. > >> There was some discussion last week about using var instead of variables. > >> And there was some discussion of not exposing variables outside the cfc. > >> So I need to put together some 'typical' examples. > >> Are there any built already? > > > >var vs. variables isn't an either/or thing. If you var scope > >something inside a cffunction, it will be local to that function, and > >you HAVE to var scope ALL your variables that are local to your > >cffunctions in order to make them thread safe. The variables scope, > >on the other hand, makes things available throughout the CFC (i.e. not > >local to a particular function, but available anywhere within the > >CFC). The variables scope also protects your variables because they > >can't be set from outside the CFC like "this" scoped variables can. > > > >Matt > >-- > >Matt Woodward > >[EMAIL PROTECTED] > >http://www.mattwoodward.com > > > > > >---------------------------------------------------------- > >You are subscribed to cfcdev. To unsubscribe, send an email to > >[email protected] with the words 'unsubscribe cfcdev' as the > >subject of the email. > > > >CFCDev is run by CFCZone (www.cfczone.org) and supported by > >CFXHosting (www.cfxhosting.com). > > > >An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
