Correct, but in this case whether the bug is fixed or not wouldn't matter because of the reference issue I have already brought up.
Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ V: 415-577-8070 F: 415-341-8906 P: [EMAIL PROTECTED] > -----Original Message----- > From: Sean A Corfield [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 02, 2002 4:05 PM > To: CF-Talk > Subject: Re: CFC theory > > Yes, these examples exploit the (well-publicized) bug that variables scope > is broken in components and instead refers to the caller's variables > scope. > > When we fix that bug, variables will 'do the right thing' and become the > private scope everyone wants to see - mirroring the unnamed scope / > variables scope similarity that exists today *outside* components. > > On Monday, September 2, 2002, at 04:04 , Pete Freitag wrote: > > > I don't think you saw what I was getting at, here is a very explicit > > example: > > > > <cfset foo = CreateObject("component", "Salary")> > > <cfset variables.salary = "123"> > > <cfoutput>#foo.getSalary()#</cfoutput> > > > > getSalary will return 123 > > > > here is an even worse example: > > > > foo.cfc: > > <cfcomponent> > > <cfset variables.x = "100"> > > <cffunction name="getX"> > > <cfreturn variables.x> > > </cffunction> > > <cffunction name="setX"> > > <cfargument name="x"> > > <cfset variables.x = arguments.x> > > </cffunction> > > </cfcomponent> > > > > test.cfm: > > <cfset foo1 = CreateObject("component", "foo")> > > <cfset foo2 = CreateObject("component", "foo")> > > <cfset foo1.setX(1)> > > <cfset foo2.setX(2)> > > <cfoutput>#foo1.getX()#</cfoutput> > > > > take a wild guess what this outputs... 2! > > > > not my idea of private. > > > > -pete > > > > > > -----Original Message----- > > From: Matt Liotta [mailto:[EMAIL PROTECTED]] > > Sent: Monday, September 02, 2002 6:38 PM > > To: CF-Talk > > Subject: RE: CFC theory > > > > > > The variable is private. However, when you use the getSalary method you > > return a reference to the private variable. This is the same in Java if > > you declare a variable as private and have a public "getter" that > > returns a reference to it. > > > > Matt Liotta > > President & CEO > > Montara Software, Inc. > > http://www.montarasoftware.com/ > > V: 415-577-8070 > > F: 415-341-8906 > > P: [EMAIL PROTECTED] > > > >> -----Original Message----- > >> From: Pete Freitag [mailto:[EMAIL PROTECTED]] > >> Sent: Monday, September 02, 2002 3:40 PM > >> To: CF-Talk > >> Subject: RE: CFC theory > >> > >>> Anything placed in the variables scope is private; bug or not. > >> > >> Depends on how you look at it, sure it's private in that you can't > > access > >> cfcInstance.salary > >> > >> But you could do something like this... > >> > >> <cfset variables.salary = foo.getSalary()> > >> <cfset variables.salary = DollarFormat(variables.salary)> > >> <cfoutput>#variables.salary#</cfoutput> > >> > >> and you will change the value of the data member inside the CFC. I > > don't > >> see > >> how you can call that behavior private, because it goes against all > > the > >> reasons you would want to have private access. > >> > >> Though I agree with you if you are saying that as long as the > > developer > >> using your CFC is aware of the bug, then you can pretend that > > variables > >> scope is private, and just avoid writing code like the code above. > >> > >> > >> > > > > > ______________________________________________________________________ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
