You're right that the point of an iterator is to mask the implementation of the underlying collection. However, it doesn't mask the individual items' implementations, which is what usually changes. CFML's collection types are minimal, and there is very little overlap, so an iterator doesn't buy you much, in my opinion. To put that another way, if you have a collection of structs, they're in an array (not a struct or a query). Same for a collection of CFCs. Contrast this with Java where you might have a Object[], a List<Object> or a Set<Object> used interchangeably; here an iterator is of much higher value.
Peter Bell's IBO is a more reasonable use of an iterator in CFML, but it's more about avoiding CFC instantiation overhead, not masking the underlying collection (though it does do that). cheers, barneyb On Thu, Apr 9, 2009 at 2:03 PM, Baz <[email protected]> wrote: > Is it *generally* good practice to use iterators to handle multiple values > for an attribute - mainly for relationships between objects - rather than > native types like arrays of objects or structs of objects (forget about the > performance issues in cf)? The problem with using native types is that if > you ever needed more logic, you would have to replace all handling of said > arrays/structs with a new object anyway. So if you start out with an > iterator that at first does little more than encapsulate an array, atleast > you are future-proofing (I use that *very* lightly) the api. Agree? > > Cheers, > Baz > > > > > -- Barney Boisvert [email protected] http://www.barneyb.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
