Comments on: Naming CFC Instance Variables https://www.barneyb.com/barneyblog/2005/06/19/naming-cfc-instance-variables/ Thoughts, rants, and even some code from the mind of Barney Boisvert. Thu, 11 Sep 2014 09:58:12 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Barney https://www.barneyb.com/barneyblog/2005/06/19/naming-cfc-instance-variables/comment-page-1/#comment-140 Barney Tue, 21 Jun 2005 14:13:29 +0000 http://barneyb.com/barneyblog/?p=99#comment-140 Whoops. You're correct, of course, Sean. CFPROPERTY should be used to document variables in the 'this' scope. I was completely off base on that one, and can offer no excuse other than I might have been tired. Whoops. You're correct, of course, Sean. CFPROPERTY should be used to document variables in the 'this' scope. I was completely off base on that one, and can offer no excuse other than I might have been tired.

]]> By: Sean Corfield https://www.barneyb.com/barneyblog/2005/06/19/naming-cfc-instance-variables/comment-page-1/#comment-139 Sean Corfield Tue, 21 Jun 2005 00:24:20 +0000 http://barneyb.com/barneyblog/?p=99#comment-139 "you should never put anything directly into the 'variables' scope in a CFC except public data fields that are clearly documented with CFPROPERTY" I totally disagree with that. First off, 'variables' scope is protected, not public. Using CFPROPERTY to document non-public data is also very misleading. CFPROPERTY is supposed to be used for public data fields in a CFC that acts as a return type in a web service. That's it. What I would suggest is that if you are writing a CFC that you expect people to extend, you need to think very carefully about what you put in the (protected) 'variables' scope since it will be visible to any CFCs that extend yours. Using variables.my.* or variables.instance.* is a good idea since it will separate the data space form the function space. "you should never put anything directly into the 'variables' scope in a CFC except public data fields that are clearly documented with CFPROPERTY"

I totally disagree with that. First off, 'variables' scope is protected, not public. Using CFPROPERTY to document non-public data is also very misleading. CFPROPERTY is supposed to be used for public data fields in a CFC that acts as a return type in a web service. That's it.

What I would suggest is that if you are writing a CFC that you expect people to extend, you need to think very carefully about what you put in the (protected) 'variables' scope since it will be visible to any CFCs that extend yours.

Using variables.my.* or variables.instance.* is a good idea since it will separate the data space form the function space.

]]> By: Barney https://www.barneyb.com/barneyblog/2005/06/19/naming-cfc-instance-variables/comment-page-1/#comment-138 Barney Mon, 20 Jun 2005 15:09:47 +0000 http://barneyb.com/barneyblog/?p=99#comment-138 Yeah, I do the same thing. ;) It's "slidable" if you're the sole user of your component, because you control both sides, and can manipulate either one to rectify any collisions. But if you're distributing your code, that's no longer the case, so you have to be extra careful to not give your end users trouble. Yeah, I do the same thing. ;) It's "slidable" if you're the sole user of your component, because you control both sides, and can manipulate either one to rectify any collisions. But if you're distributing your code, that's no longer the case, so you have to be extra careful to not give your end users trouble.

]]> By: Joe Rinehart https://www.barneyb.com/barneyblog/2005/06/19/naming-cfc-instance-variables/comment-page-1/#comment-137 Joe Rinehart Mon, 20 Jun 2005 12:31:53 +0000 http://barneyb.com/barneyblog/?p=99#comment-137 Hey Barney, I'm not sure I 100% agree. While I agree that it's definitely a best practice to put instance data into a specific "scope", such as variables.instance, there are times when a component has members that aren't necessarily parts of its instance or state. I've both put these directly into variables and put them in another 'special' scope. Hey Barney,

I'm not sure I 100% agree.

While I agree that it's definitely a best practice to put instance data into a specific "scope", such as variables.instance, there are times when a component has members that aren't necessarily parts of its instance or state. I've both put these directly into variables and put them in another 'special' scope.

]]>