I can't agree that this is the same as in Java. In Java, I can define an instance variable as private and then set it to an identically named argument passed into a method. You've said that the unnamed scope is the way to implement private instance variables, yet the code shows that you cannot set the unnamed scope to an identically named argument passed into a method. Why not simply allow the "this" scope to contain private as well as public variables?
Hal Helms Preorder "Discovering ColdFusion Components (CFCs)" at www.techspedition.com -----Original Message----- From: Sean A Corfield [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 4:38 PM To: CF-Talk Subject: Re: CFC theory 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 >> >> >> >> > > ______________________________________________________________________ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
