yep, and we have too on occasion. broken down functionality into more logical bite-sized pieces.
the problem there is - type checking and checking for empty/missing arguments. if it's a bean being populated by a form it's all strings anyway so the type checking is internal. can you imagine 150+ if StructKeyExists() and isNumeric()/isDate() needing to be coded up inside the bean? icky.... - documentation. again, using a DTO bean as an example, having 3 structs and an additional single value or two tells you nothing about what that bean needs if you brought it up in the CFC explorer. I have been kicking the idea around of smaller sub-objects/beans that still do the same thing as the smaller structs but encapsulating the type/exists logic within them. instead of each struct having domain over it's data (keys) it takes it further with validation. The trouble there is you run the risk of disappearing up one's own backside with smaller and smaller objects. Mandelbrot-set objects. the more you look the more you find... On 4/3/06, Shib71 <[EMAIL PROTECTED]> wrote: > If a function needs more than a half dozen arguments I use a struct. > > Blair > > > On 4/3/06, Barry Beattie < [EMAIL PROTECTED]> wrote: > > > I'm thinking of this from a code management/maintainance point of view. > > someone's got up to 50 and lived to tell the tale. more is possible. > > but is it practical? and what's the alternative? > > or just live with it? if the been/object/whatever needs 'em all just do it? > > anyone want ot share their experiances? > > thanx > barry.b > > > ---------------------------------------------------------- > 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] ---------------------------------------------------------- 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]
