Something has puzzled me and I wonder if you'd care to comment on it: We
know that CF is a weakly-typed language, yet CFCs allow returntypes to
be defined for methods and types to be defined for arguments. If this is
done, CF will enforce some form of runtime type-checking.
Correct. It will check a very simple condition:
if type of entity ne specified type
throw exceptionWhat would be the major impediment to overloaded methods then? If we can
and do have runtime type-checking, wouldn't overloaded methods be at
least possible? I suspect, though, that there's something I don't
understand that would make this impractical, but I'd love to know what
it is.
As someone who had to implement overloading in a C++ parser, I'll comment:
Firstly, overloading requires that the processor analyze the set of possible methods that can be called against the actual call arguments. That's essentially an order n-squared algorithm (technically it's n x m where there are n arguments and m candidate methods). Performance dictates that you don't do this at runtime!
Secondly, you can actually get ambiguities very easily. Consider these two methods:
<cffunction name="foo">
<cfargument name="a" type="numeric">
<cfargument name="b" type="string"> <cffunction name="foo">
<cfargument name="a" type="string">
<cfargument name="b" type="numeric">Both of those can be called by:
obj.foo(123, 456);
Also, consider this option too:
<cffunction name="foo">
<cfargument name="a" type="string">
<cfargument name="b" type="string">That can also be called by:
obj.foo(123, 456);
So not only do you need to figure out valid candidates but then you get a list of matches that you have to disambiguate. In the above case, there is no way to pick a 'best' match.
Overloading gets very complex, very quickly. You pretty much can't do that sort of thing at runtime...
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
