Thanks all for comments on this thread. On Joe's point, it _is_ a bit weird to jump between the worlds of Java (where even String is an Object) to CF (where a composed structure like an array is not treated like an object). One of my concerns in the original post was that I want to ensure that this array property contains only items of a specific type. In talking to one of my co-workers he suggested extending coldfusion.runtime.array and overriding its methods. Then I had to explain that CF arrays are operated on externally (eg ArrayInsertAt(array,index)). What I end up doing is like what Sean suggested with specialised get/setters and inside these checking the args for the proper type. I basically just want to make sure that implementors can't pass trash into my array. As a result, when I want to persist or do any operation on the whole array I have to make sure to check all of its members. This is ugly and leaves room for improvement on the performance side (although as I have mentioned, these arrays are expected to contain way less than 20 elements).
Questions: 1)would I be better off using a Java native collection type for this (which could natively enforce the type like " permission [] myPermissionArray = new permission [];")? 2)Is anyone extending members of the coldfusion.runtime package and getting anything useful out of it? Cheers, Chip -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nathan Dintenfass Sent: 03 April 2004 15:09 To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Protecting private Array variables using get/set Whatever the underlying implementation of coldfusion.runtime.Array, it copies by value, not by reference. This was a design decision made long ago, for better or for worse, and the CF team has been pretty religious about backwards compatibility. <cfscript> foo = arrayNew(1); foo[1] = "original value"; foo2 = foo; foo2[1] = "new value"; writeOutput(foo[1] & " != " & foo2[1]); </cfscript> > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Joe Eugene > Sent: Saturday, April 03, 2004 11:33 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Protecting private Array variables using get/set > > > > >As pointed out elsewhere, arrays are copied by value > > I thought CFMX Arrays are Java Vectors and Not really Primitive > Java Arrays. So arent arrays passed by Reference.. since they > are true objects? > > Am i missing something? > > Thanks, > Joe Eugene > > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >Behalf Of Sean A Corfield > >Sent: Friday, April 02, 2004 6:49 PM > >To: [EMAIL PROTECTED] > >Subject: Re: [CFCDev] Protecting private Array variables using get/set > > > > > >On Apr 2, 2004, at 8:11 AM, John Temm wrote: > >> Ideas? Is it generally not a good idea to use arrays for properties > >> because of this? > > > >As pointed out elsewhere, arrays are copied by value so where you can > >actually get into trouble is if you try to use the getArrayProperty() > >method internally to operate on the elements (rather than using > >variables.arrayProperty directly). It's one of the few places where you > >can't exclusively use getters inside your components - but you could > >setArrayPropertyAt(value,index) / getArrayPropertyAt(index) if you > >needed to encapsulate raw access to the array... > > > >However, if you're concerned about passing references out of getters, a > >more common pitfall is when folks return a struct property and forget > >to duplicate() it. Of course, in most cases you wouldn't return a plain > >struct - you'd either return the components of the struct separately > >(in separate getters) or you'd want to encapsulate the structured data > >in another component, i.e., use a CFC instead of a struct. > > > >Finally, passing arrays around might be a performance concern - since > >the entire array is copied on every assignment. Not really a problem > >for small arrays but I've seen CFers innocently pass around large > >arrays with abandon... > > > >Regards, > >Sean > > > >---------------------------------------------------------- > >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] ---------------------------------------------------------- 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]
