All this simply argues that reusing the same name in different scopes is rightly considered bad practice. Note that this collision is *exactly* the same as in Java where arguments scope takes priority over instance scope.
On Monday, September 2, 2002, at 01:29 , Hal Helms wrote: > Look at this code, Matt, for a Quandry.cfc: > > <cfcomponent hint="I am a Quandry"> > <cfset salary = "200000"> > <cfset taxRate = "0.57"> > > <cffunction name="setSalary" access="public"> > <cfargument name="salary" type="numeric"> > <cfset salary = arguments.salary> > </cffunction> > > <cffunction > name="reportNetIncome" > access="public"> > <cfreturn salary - computeTaxes()> > </cffunction> > > <cffunction name="computeTaxes" access="private" > returntype="numeric"> > <cfreturn salary * taxRate> > </cffunction> > </cfcomponent> > > Here's some test code: > > <cfset q = CreateObject( 'component', 'Quandry' )> > > <cfoutput> > I netted #DollarFormat( q.reportNetIncome() )# this year. > </cfoutput> > > It outputs $86,000, as expected. > > Now use this test code: > > <cfset q = CreateObject( 'component', 'Quandry' )> > <cfset q.setSalary( 500000 )> > > <cfoutput> > I netted #DollarFormat( q.reportNetIncome() )# this year. > </cfoutput> > > It still reports 86,000, indicating that something is amiss in the > setSalary() method. But if you change the setSalary() method so that the > argument name is different from the instance variable, like this: > > <cffunction name="setSalary" access="public"> > <cfargument name="_salary" type="numeric"> > <cfset salary = arguments._salary> > </cffunction> > > Then the same test code returns $215,000, a number I think you'll agree > is much friendlier. > > Hal Helms > Preorder "Discovering ColdFusion Components (CFCs)" at > www.techspedition.com > > -----Original Message----- > From: Matt Liotta [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 02, 2002 3:54 PM > To: CF-Talk > Subject: RE: CFC theory > > > Why doesn't your code work? Seems perfectly acceptable to me assuming > you have already declared score outside of the function. > > 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: Hal Helms [mailto:[EMAIL PROTECTED]] >> Sent: Monday, September 02, 2002 12:58 PM >> To: CF-Talk >> Subject: RE: CFC theory >> >> Another problem with the unnamed scope is that you can't have this: >> >> <cfset score = arguments.score> >> >> That puts a needless restriction that instance variables be named >> differently from arguments and reduces the readability of code, IMHO. >> >> Hal Helms >> Preorder "Discovering ColdFusion Components (CFCs)" at >> www.techspedition.com >> >> -----Original Message----- >> From: Hal Helms [mailto:[EMAIL PROTECTED]] >> Sent: Monday, September 02, 2002 3:48 PM >> To: CF-Talk >> Subject: RE: CFC theory >> >> >> I agree with you completely, Matt. I object to CFCs using the "this" >> scope and making this public. It removes virtually all of the benefits > >> of having it. This could easily have been overcome by allowing us to > set >> access attributes such as private. But using an "unnamed scope" seems > to >> me to be a kludge to get around what should have been implemented. >> Having a <cfproperty> tag with an access attribute (or some such >> mechanism) would make perfect sense. >> >> The term, OO, is not merely an imprimatur that marketing can annoint a > >> product with if it is to mean anything at all. We should be able to >> expect that "this" is a private scope, that CFCs would have > overloadable >> methods, overloadable constructors, etc. >> >> Hal Helms >> Preorder "Discovering ColdFusion Components (CFCs)" at >> www.techspedition.com >> >> -----Original Message----- >> From: Matt Liotta [mailto:[EMAIL PROTECTED]] >> Sent: Monday, September 02, 2002 12:24 PM >> To: CF-Talk >> Subject: RE: CFC theory >> >> >>> Let's see: CFCs have given us a "this" scope which is *public*; >> instance >>> variables can't be made private except by the kludge of using an >> unnamed >>> scope. We have CFCs presented as OO, but which has no concept of >> super. >>> We have no overloading of methods in CFCs. >>> >> I don't really think making variables private within CFCs is a kludge. > I >> do however feel the implementation of CFCs is generally poor. IMHO, > the >> cfproperty tag should declare variables for a CFC and should include > an >> attribute for public or private access. Further, any variables > declared >> with cfset should be private within the context of where they were >> declared. This would enable function scoped variables automatically >> without having to use the stupid var keyword. >> >> I do wish CFCs were more Java like, but I wouldn't be so quick to say >> they aren't OO. >> >>> Were I given to irony, I might say that "I am not anti-CFC per se, > but >> >>> it does tend to live in its own little bubble and it takes words, >>> concepts and phrases from the much larger world of OO and misuses > them >> >>> in a way that causes confusion." >>> >> I think a perfect example is ColdFusion Component, which is nothing > more >> than a class. >> >> -Matt >> >> >> >> > > ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.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
