> Right... that is a style. I have voted on the CF wish list for
> "protected attributes".
I might be misunderstanding what you're trying to say, but the variables
scope has similar visibility to "protected" in Java. What's missing is
"private".
> Right now this is the way I set externally
> visible attributes that don't modify internal variables the CFC uses.
> They are not "protected" but the internal workings of my CFC are safe.
It sounds like you're referring to built-in property accessor methods a la
VB, C#, and Java beans?
> I
> create a (variables.attributes) structure to hold the attributes I
> typically expose in this scope. Most of my CFCs that do that function
> simply duplicate that structure out to the this scope.
I think the question is over whether or not the columns should be put
directly in the "this" scope or in a sub-struct like
"this.columns.myColumnName". By taking this approach, you eliminate the
possibility that a column named "isLast" is going to overwrite your isLast()
function reference.
> Changing those values won't cause the CFC to fail... but there is an
> issue. Even PHP has a protected scope for this... in fact so does JAVA
> and Microsoft solutions. This is one strong wish list issue that we need
> in the next upgrade of CF. If we had a protected scope you guys wouldn't
> be afraid to do things this way. The process is logical... it's just not
> protected.
I think we're all talking about different things. My understanding of the
second (preferred) suggestion was to use a method to query a column name:
myIterator.getColumn("myColumn")
Instead of building out your attributes every time the position changes, you
would wait (in a fashion similar to lazy initialization) until the client
caller requested the value of the column:
<cffunction name="getColumn" access="public" returntype="string"
output="no">
<cfargument name="columnName" type="string" required="yes">
<cfreturn variables.query[arguments.columnName][getCurrentRow()]>
</cffunction>
Obviously, you'd want some error checking and such. Also, as mentioned in my
previous message, I probably wouldn't reference the query directly, instead
relying on an accessor method.
> Respectfully the inner workings are safe. We both agree for now the
> inner code of the CFC should never address the object attributes from a
> logic perspective. In other words the functions should never reference
> the attributes to perform logic. In fact the way I do it... the
> attributes are just a way of exposing internal settings of the object.
> Currently the attributes cannot be protected and should rarely and
> mostly never be used to pass information into a CFC. Yet... it is a way
> to get information out of a CFC. When you do a CFDump for example you
> can see all the attributes. It does serve you well for debugging and
> programming. (Just a style issue... again...
Actually, it's not just a style issue. You can run into naming collisions
the way you've done. You also take a pretty severe performance penalty your
way (according to the stats posted earlier).
> go to wish list and vote
> for change if they don't add it to the next beta.)
I'm still not sure what feature you're asking for. I don't think the
suggestions made pertain to the private/protected/public visibility of the
columns. It's whether or not to take the hit copying the data to the this
scope and, if so, how to do it without naming conflicts.
Anyway, debugging is a good reason to do it. However, personally, I probably
would have added a separate method for that (getCurrentRecord()) which
returns all the values in a simple struct.
Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057
----------------------------------------------------------
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]
