There was a brief discussion I had on the 'variables.' issue a few weeks
ago on this issue within a CFC. I actually create a private struct,
<cfset _me = structNew()> and then assign all private variables for a
CFC into this structure. E.g. <cfset _me.name = "foo">. I also now use
a similar struct at the function level, <cfset var local = structNew()>
, to scope all local variables at the recommendation of some others on
this list. I know the recommendation some might make is to use the
'variables._me.name' or 'variables.local.name' but that is just too
much unnecessary typing in my book. Additionally the _me approach and
local approach tell me exactly who 'owns' the variable so it has made it
very easy to differentiate b/w CFC level scope and function level scope.
Additionally I read in Ben Forta's CFMX Certification guide a good
reason as to why not to specify scope and it was for the added
flexibility not including it brings. In the book there were
specifically referring to reading from form or url scopes and that by
not specifying scope you have the flexibility to switch b/w the two.
I've taken this line of thinking and opted to apply this to the
'variables.' issue. If the next version of MX decides to strengthen
scope w/in a CFC (something I very much in favor of them doing) I'm
covered with this approach. If they don't I'm still fine. Even if these
approaches add a few extra microseconds at runtime, the added clarity
they are bringing to the code is proving invaluable.
-Jason Daiger
www.jdaiger.com
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
