Ben, These are exactly the reasons for my suggestions last night :) Did my revised version of the CFC make it to the list around 10:40-ish? Sometimes they get dropped. It has your suggestions incorporated, and some performance tuning that cuts the iteration time to about 10% of the original.
Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Rogers Sent: Thursday, February 24, 2005 10:40 AM To: [email protected] Subject: RE: [CFCDev] query object CFC Beta > 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] ---------------------------------------------------------- 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]
