>
>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:
>
They would be called as either named parameters or declared with the
optional arguments at the end.
That brings up another interesting thing that I only noticed the other
day...
If you are calling a private method in a CFC from a public method you can't
pass the arguments as name=value pairs:
eg.
test.cfc
<cfcomponent>
<cffunction name="publicone" access="public">
<cfargument name="arg1">
<cfreturn variables.privateOne(arg2=arguments.arg1)>
</cffunction>
<cffunction name="privateone" access="private">
<cfargument name="arg2">
<cfreturn "It works">
</cffunction>
</cfcomponent>
test.cfm
<cfset test = createObject('component','test')>
<cfset test.publicOne(arg1="test")>
Not sure if that is known behaviour, but it surprised me.
><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>
Yes, that would be better.
I would probably prefer it if the update() and insert() methods weren't
linked together by the save() method, but that's not really relevant to this
discussion.
The point was really that there are ways to write valid code so that not
scoping the arguments causes issues, but then again there are also lots of
ways to write valid code so that not scoping the arguments doesn't cause
issues.
In principle I think it is better to always scope variable references where
possible, but that doesn't mean I'm not above a bit of laziness myself. Just
look at any of the code examples on my blog and you'll see a host of
unscoped variables all over the place ;)
Spike
>
>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]
----------------------------------------------------------
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]
