So lets assume MM added support for true overloading. Say an attribute of the cfcomponent tag allowed either the current one method per name, w/ optional arguments or multiple method definitions per name with different required arguement sets.

If I show you the API for a method that looks like:

myCFC.method(string)
myCFC.method(string, numeric)
myCFC.method(string, numeric, numeric)

did I use true overloading, or did I just define a method with one required and 2 optional arguments? And why should you care which since the principle of encapsulation says you shouldn't care about how it is implemented.

So while it isn't true overloading, that's not real practical in a weekly typed language like CF and actually I think it comes out ahead as far as ease of development and flexability, especially when used with argument=value syntax.

Sean A Corfield wrote:

On Monday, Aug 4, 2003, at 18:59 US/Pacific, JerryEla wrote:

I would contend CFMX supports overloading, just in a very un-java way. Instead of defining multiple methods with different argument sets, you define a single method with optional arguments.


That's not overloading. Overloading is *specifically* where you have multiple methods with the same name and the language processor chooses the best match to call.

Now, where did I put that draft white paper "99% of Overloading is Bad"...?

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).


----------------------------------------------------------
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).

Reply via email to