While you can't really extend the native object in CF you can abstract them.
I've done this to create "Collection" classes - collections, internally, are
just structs, but are accessed via custom methods such as "add()", "Drop()",
and so forth. It offers abstracted interfaces to sorting (using
StructSort() and a QuickSort implementation) and various other geegaws.
Another abstraction "OrderedCollection" does the same thing with Arrays with
methods like "promote()", "demote()", etc
In my system you create a collection by defining the object type of the
collection (the type of components you're going to store in the collection).
For example:
<cfset Foos = CreateObject("Component", "DP_Collection").init("Foo")>
The "Foos" collection can then only accept "Foo" objects. Type checking is
done via methods in a universal "DP_Component" component extended by all
others.
Once you build the collection abstractions you're pretty much set - you
don't have to bother much with anything other than populating them.
Jim Davis
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of John Temm
Sent: Monday, April 05, 2004 1:32 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] Protecting private Array variables using get/set
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]
----------------------------------------------------------
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]
