I can think of three rationales for mixins: 1. To make dynamically defined "helper" methods available to clients of the original object. This can't be done by simple delegation - you have to know about a method before you can delegate it, and the mixin might not be known until runtime.
2. Where the methods are known but not always wanted, like debugging hooks. You might have a debugging factory method that mixes debugging methods into all your objects, where the production factory method does not. 3. Where you really could handle it with delegation but are too lazy to write all the delegation methods. I think it's this last one you're expressing a dislike for. In general I would agree with you. Oh, I just noticed you were looking for replies from smart experienced folks. Oh, well, too late now...;) Jaime Metcher > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barry > Beattie > Sent: Thursday, 1 February 2007 2:58 PM > To: [email protected] > Subject: Re: [CFCDEV] Closures, mixins, and udf includes > > > more like > > > objA = CreateObject("component", > "A").init(application.kernel.getHelper()); > > <cfcomponent name="A"> > > <cffunction name="init"> > <cfargument name="helper" type="any" hint="helper > routines in a CFC to decorate this CFC" /> > <cfset variables.helper = arguments.helper /> > <cfreturn this /> > </cffunction> > > </cfcomponent> > > (actually for smaller jobs I've just been passing a reference to the > kernel into the CFC and running the getHelper() within there, since > most of the time the CFC actually decorates the kernel - think of it > as a reference back to the parent) > > > What hassle? > > two things I don't like about includes (within CFC's) are: > managing the include files in conjunction with CFC. in a case of an > include for each SQL statement where there's 50 of them that's 51 > files to move around. > > documentation: comming across a helper method and asking "WTF is this > and where did it come from?" instead of <cfreturn > variables.helper.doSomething(result) /> and additionally, seeing what > helper.doSomething() is in the CFC explorer. Perhaps I've been burnt > by Fusebox 3 bad practices? > > I realise that everyone has their favourite mousetrap. I just prefer > to have methods (even static ones) within CFC's. Infact the only time > I bother now-a-days with cfinclude is for taglibs for the UI. > > different strokes, etc. > > cheers > b > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
