>Overloading works by analyzing a function call against the possible
function signatures that can be called. The set of available functions
to call is filtered down to just those that can actually be called with
the given arguments. Then that set is reduced to a "best match". That
sort of analysis is expensive and that's why it's a compile-time feature
of Java, C++ etc.
Fair call. But CFMX *is* "compiled" to Java, so that's when it's being
done in CF too - albeit via a circuitous route - surely? I guess
there's a pseudo compile taking place (some sort of cfm->class
transformation, but there doesn't seem to be any linking going on, so
the calling template happily "compiles", without checking that all the
"support" code is there, just thinking "oh well: if it's not there when
I get run, *then* I'll error". Grumble ;-)
> ColdFusion is a type-less language (almost) so the only way
overloading could be implemented in CF is at runtime. The overhead would
be prohibitive.
This is a good point.
My only thought regarding this (and this is for the purpose of
conversation, not validating my idea, or suggesting a solution), would
be force casting (javacast()) where the argument sets could be
interpretted ambiguously.
Eg:
<cfmethod name="foo" output="false" returntype="boolean">
<cfargument name="bar" type="numeric" required="yes">
</cfmethod>
<cfmethod name="foo" output="false" returntype="boolean">
<cfargument name="bar" type="string" required="yes">
</cfmethod>
...
<cfset result = cfc.foo(1)>
In CF, "1" could equally be a string or a numeric. Hmmm...
Oh well.
Adam
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
