They are simply for validation and they make sense in a strongly typed or typeless language. There are plenty of times when you would want to determine if a string is a valid number even though it is a string. Obviously, arrays, structs, and queries are special cases.
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 2:11 PM > To: CF-Talk > Subject: RE: CFC theory > > I think the problem is that CF is "moderately" typed, something we're > not used to. Otherwise, what would such functions such as isNumeric(), > is Array(), isStruct() as well as the "type" attribute in <cfargument>, > in <cfproperty>, and the "returntype" attribute in <cfcomponent> mean? > > Hal Helms > Preorder "Discovering ColdFusion Components (CFCs)" at > www.techspedition.com > > -----Original Message----- > From: Matt Liotta [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 02, 2002 4:59 PM > To: CF-Talk > Subject: RE: CFC theory > > > Oh no! CF does not do type checking as there are no types. CF does > provide a built-in way to validate data that though. These two things > are not the same. > > 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:57 PM > > To: CF-Talk > > Subject: RE: CFC theory > > > > But CF does type checking for return types and argument types. It > allows > > polymorphism by checking the type, so why can't we expect it to know > > enough to sort out the type of the argument passed to it? > > > > 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:32 PM > > To: CF-Talk > > Subject: Re: CFC theory > > > > > > On Monday, September 2, 2002, at 12:48 , Hal Helms wrote: > > > I agree with you completely, Matt. I object to CFCs using the "this" > > > > scope and making this public. > > > > Why? "this" scope in Java is for public data members (as well as > private > > > > data members). "this" scope in C++ is for public data members (as well > > > as private data members). > > > > > But using an "unnamed scope" seems to > > > me to be a kludge to get around what should have been implemented. > > > > Elsewhere in CF 'variables' and the unnamed scope are synonymous. We > > have already acknowledged a bug that 'variables' does not behave > > correctly inside components. That bug will be fixed. > > > > > 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. > > > > Since "this" is *not* a private scope specifically in any OO language > I > > can think of, I think your expectations are wrong - based on lack of > > knowledge of other OO languages perhaps? > > > > As myself and Matt have pointed out, overloading belongs in strongly > > typed languages, not typeless ones. > > > > Sean A Corfield -- http://www.corfield.org/blog/ > > > > "If you're not annoying somebody, you're not really alive." > > -- Margaret Atwood > > > > > > > > ______________________________________________________________________ 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
