I'm not going to get into the OO/non-OO argument, but if you're using CFCs in an OO manner (not perfect, definitely doable), then it makes sense to use as much OO patterning as possible. Not to say "definitely don't do it", but if you're mixing paradigms like that, it's worth taking a close look at the reason, because it's usually more than just a coincidence. Forcing someone maintaining the app to deal with that multi-paradigm setup isn't very nice either.
Sharing code across CFCs is one place that I refuse to agree that CFINCLUDE is a good thing. Make a CFC out of it, and instantiate it in each CFC that needs the functionality. I could potentially see the need for a function to be used as both a CFC method, and a standalone UDF, but even then I think it'd be much preferable to roll it into a separate CFC. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Adam Cameron > Sent: Tuesday, July 06, 2004 4:13 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Serialization of CFCs > > >> The bottom line is basically, don't use cfinclude within CFCs. > > >It would be bad OO practice anyway. > > And if CF was an OO language, that would be relevant. > > CF's *not* an OO language, and when working within its limitations, > sometimes it's preferable to share some code across CFCs. > > I can't understand how people get some dogmatic about going > all OO about > CF just because it's got CFCs now. > > Adam ---------------------------------------------------------- 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]
