Just had to deal with a problem where overloading would have been
extremely handy the other day, and ran into a few issues with the
argumentCollection, that weren't addressed in your blog (which btw is
.
Theoretically, I'm thinking it should be possible to do this, and the
invoked method would happily do it's thing. I'm using cfinvoke so
there is less ambiguity.
<cffunction name="saveEstimate">
<cfset var estimate_id = ''>
<cfswitch expression="#arguments[1]#">
<cfcase value="labor">
<cfinvoke
method="insertEstimateLabor"
returnvariable="estimate_id">
<cfinvokeargument name="argumentCollection"
value="#arguments#">
</cfinvoke>
</cfcase>
<cfcase value="parts">
<cfinvoke
method="insertEstimateParts"
returnvariable="estimate_id">
<cfinvokeargument name="argumentCollection"
value="#arguments#">
</cfinvoke>
</cfcase>
</cfswitch>
<cfreturn estimate_id>
</cffunction>
<cffunction name="insertEstimateLabor">
<cfdump var="#arguments#">
</cffunction>
If this worked...it would seem to be a fairly elegant solution to
overloading. I'm testing values of arguments here, but it's
applicable to any situation where overloading comes in handy.
But what actually happens is really strange. The order of the elements
in the arguments collection in the invoked method is seemingly
randomly mixed, and if a structure is passed, it's shows up as
[undefined struct element] in the arguments collection, and causes
cfdump to throw an error, saying that the var parameter is undefined
if I try to access the mystery struct directly. This sounds very
similar to bug 46687 that was supposedly fixed in 6.1, but this is
happening on my 6.1 machine.
I don't think I'm trying to do something that wasn't intended, as
I can't think of another reason for argumentCollection, other than to
pass around arguments...but who knows. I'd love some clarification on
this.
--
mailto:[EMAIL PROTECTED]
Monday, August 11, 2003, 5:09:04 PM, you wrote:
SAC> On Tuesday, Aug 5, 2003, at 17:56 US/Pacific, JerryEla wrote:
>> If I show you the API for a method that looks like:
>>
>> myCFC.method(string)
>> myCFC.method(string, numeric)
>> myCFC.method(string, numeric, numeric)
SAC> The point here - as you acknowledged - is that you can do this with CF
SAC> as it stands today by using optional arguments on a single method.
SAC> Furthermore, you can define a method that takes, say, one argument and
SAC> you can still call it with as many arguments as you want:
SAC> <cffunction name="foo" returntype="void">
SAC> <cfargument name="a" type="string" required="true" />
SAC> <!--- only one official argument! --->
SAC> <cfif arrayLen(arguments) eq 10>
SAC> <!--- user supplied ten arguments! --->
SAC> ...
SAC> </cfif>
SAC> </cffunction>
SAC> You don't need any sort of overloading feature added to the language to
SAC> support this.
SAC> Sean A Corfield -- http://www.corfield.org/blog/
SAC> "If you're not annoying somebody, you're not really alive."
SAC> -- Margaret Atwood
SAC> ----------------------------------------------------------
SAC> You are subscribed to cfcdev. To unsubscribe, send an email
SAC> to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
SAC> in the message of the email.
SAC> CFCDev is run by CFCZone (www.cfczone.org) and supported
SAC> by Mindtool, Corporation (www.mindtool.com).
----------------------------------------------------------
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).
