I disagree. What you are suggesting is a lame use of overloading that could easily be handled by an if statement. Simply make the address parameter optional and check for its existence. IMHO, overloading should only be used for strongly typed languages.
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:53 PM > To: CF-Talk > Subject: RE: CFC theory > > Overloading means that a method or constructor can have multiple "method > signatures". For example, an overloaded constructor for Person() might > have the following Person(), Person(firstName, lastName), > Person(firstName,lastName, address), etc. Not having this ability means > that we have to resort to all sorts of workarounds while a standard OO > implementation of overloading would eliminate this problem. > > Hal Helms > Preorder "Discovering ColdFusion Components (CFCs)" at > www.techspedition.com > > -----Original Message----- > From: Jeffry Houser [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 02, 2002 1:29 PM > To: CF-Talk > Subject: Re: CFC theory > > > At 09:27 AM 9/1/2002 -0700, you wrote: > > > > 3. Is the data created inside a component protected from outside > > > forces? I'm a little grey on this one. You can create component > > > specific variables using the this scope. > > > >"this" scope is public, the unnamed scope is private so this gets a > >YES. > > :hmm: That is interesting. I don't like un-named scopes. I wish > someone at Macromedia took a little time to document this stuff. > I thought the variable was automatically put into the this scope. I > have to agree with Hal on this one. That is a kludge. The scope should > > have a name. A scope named private would have been a better option. > > > > > 2. Do CFCs support Overloading / Overriding? Not in related > > > objects. > > > >Overloading no, overriding yes. (And I don't really agree that > >overloading is actually *necessary* to claim 'OO-ness' - much of the > >worst code I have seen in OO languages is because of overloading and > >there are almost always ways around it). > > > Allow me to bang my head on the desk. I was using the two terms > interchangeably. > I doubled checked my OO book and it uses the term overloading > exclusively. What exactly is overriding, then? > > > > > A child CFC inherits all parent > > > methods as is. You do not have the ability to change functionality > > > of inherited methods. > > > >Yes you do. Try the following: > > > > // base.cfc: > > <cfcomponent> > > <cffunction name="foo" returntype="string"> > > <cfreturn "I'm base.foo"/> > > </cffunction> > > </cfcomponent> > > > > // derived.cfc: > > <cfcomponent extends="base"> > > <cffunction name="foo" returntype="string"> > > <cfreturn "I'm derived.foo"/> > > </cffunction> > > </cfcomponent> > > > > // test.cfm: > > <cfset b = createObject("component","base")/> > > <cfset d = createObject("component","derived")/> > > <cfoutput> > > b.foo() is #b.foo()#<br> > > d.foo() is #d.foo()#<br> > > </cfoutput> > > > >You can pass d to anything expecting a base component instance so > >substitutability is preserved and polymorphism is also preserved. > > You're right. When did this creep into the product? I'd bet my right > > arm that this was not supported during the beta cycle? > > > > > > > 3. Do CFCs support inheritance? Yes, they do. However without the > > > overloading / overriding it is nothing more than a fancy include. > > > >Overloading is mostly irrelevant for inheritance - in most (all?) OO > >languages, when you inherit an overloaded set of methods, you have to > >reimplement all of them in order to preserve overloading - overloading > >normally only occurs within each class definition. > > > >As pointed out above, CFMX does have overriding so inheritance *is* > >more than a fancy include. > > Yes, you are right. I retract my original statement. It was based on > > incomplete facts. > > > > > > 4. Do CFCs support polymorphism? I would say no. I cannot create > > > two different methods with the same exact name, but different > > > argument types. That is the essence of polymorphism. > > > >No, that is overloading. Polymorphism requires overriding - see above - > > >so CFMX *does* support polymorphism. Polymorphism is 'virtual > >functions' in most every OO language, something that CFMX does have. > > > > > For me, the lack of the ability to overload is what makes me say you > > > > cannot apply Object Oriented development > > > >As I say above, overloading really has nothing to do with OO. C has > >overloading (Oh, yes, it does! Check out the latest ISO C standard to > >see how they worked that in. Not for all types, admittedly, but they > >did add it). > > > > >(Do I need to mention that I wrote the first ANSI-validated C compiler, > > >spent eight years on the ISO C++ Standards Committee - three as > >secretary > >- designing parts of that language and also worked on the UK and ISO > Java > >Study Groups for a couple of years as well? :) > > ;) Then I'm sure you'll have no trouble drilling the differences > between > overloading and overriding into my head? > > > > -- > Jeffry Houser | mailto:[EMAIL PROTECTED] > Need a Web Developer? Contact me! > AIM: Reboog711 | Phone: 1-203-379-0773 > -- > My CFMX Book: > <http://www.amazon.com/exec/obidos/ASIN/0072225564/instantcoldfu-20> > My Books: http://www.instantcoldfusion.com > My Band: http://www.farcryfly.com > > > ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com 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
