You're correct, I forgot about the naming issue. You are supposed to the
following cfset inside the setSalary method.
<cfset variables.salary = arguments.salary>
Which is not all that different from using the this scope in Java.
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 1:30 PM
> To: CF-Talk
> Subject: RE: CFC theory
>
> 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/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
