4. Multiple Inheritance - A person can be an engineer and a husband and
any other number of things. How can you have this functionality unless
you are putting a bunch of methods in the Person class that don't really
belong.
Jaime Metcher wrote:
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]
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]
