Yeah, I meant optional.  My bad.

Interesting.  So in that situation, the methods would be called with named
parameters, not positional ones, eh?  I'd never really thought about that
kind of usage.  And even like this, you can do it without undefaulted
optional params, and get some better method breakdown (IMHO) as well:

<cffunction name="save">
  <cfargument name="id" type="string" required="false" default="" />
  <cfargument name="name" type="string" required="true" />
  ...

  <cfif len(id) GT 0>
    <cfset update(arguments) /> <!--- a good use of arguments!! --->
  <cfelse>
    <cfset insert(arguments) />
  </cfif>
</cffunction>

<cffunction name="update">
  <cfargument name="id" type="uuid" required="true" />
  <cfargument name="name" type="string" required="true" />
  ...

  <!--- UPDATE query --->
</cffunction>

<cffunction name="insert">
  <cfargument name="name" type="string" required="true" />
  ...

  <!--- INSERT query --->
</cffunction>

Cheers,
barneyb

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Milligan
> Sent: Friday, March 19, 2004 4:17 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] Unscoped references in CFSET within CFFUNCTION
> 
> >Required arguments without a default?  How often do you run 
> >across those?
> >It seems to me that if you're declaring an argument, you'd 
> >always specify a default, because you want that variable to be 
> >there.  Otherwise you'd just use an implicit argument and 
> >dereference it out of the arguments array/struct.
> 
> Did you mean optional arguments without a default?
> 
> Giving a required argument a default value seems kinda 
> strange, but maybe
> I'm missing something.
> 
> As far as not specifying a default, I've seen people using 
> code like this:
> 
> <cfunction name="saveProduct">
>       <cfargument name="productid" type="uuid" required="false">
>       <cfargument name="productname" type="string" required="true">
>       etc...  
> 
> 
>       <cfif isDefined('arguments.productid')>
>               <!--- We're doing an update, so run the update 
> query --->
>       <cfelse>
>               <!--- We're doing a crate, so run the insert query --->
>       </cfif>
> 
>       etc...
> </cffunction>
> 
> The productid has to be a UUID if it is supplied. If it is 
> not supplied you
> want to be able to tell so that you run the create operation. If it is
> supplied it must be an update operation.
> If you don't scope any references to productid in ARGUMENTS 
> you could get
> all sorts of bad things happening if productid exists somewhere in the
> implicit lookup scopes.
> 
> Whether it is a good idea to be relying on that sort of construct is a
> different question entirely, but it is certainly valid.
> 
> 
> >
> >Not to say that's not a good reason for using the arguments 
> >scope, but it seems a strange position to put yourself in to 
> >begin with.
> 
> Indeed, but I have seen a lot of code where that is exactly 
> what people have
> done.
> 
> ----------------------------------------------------------
> 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]
> 

----------------------------------------------------------
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]

Reply via email to