Sean Corfield showed something along the same lines several months back at BACFUG. Unfortunately, the main issue is that using this machinery at run-time would typically be much more overhead than you'd want given the benefit of the check.
If you are going to build your own machinery, I'd personally much rather see "implements" as an attribute of CFCOMPONENT -- since you are going to introspect metaData anyway, that would seem to me a much cleaner place to put it. You'd still need to call a method from your parent CFC in every CFC you want to check for, though, because the metaData of the child won't exist in the parent -- but you could just call it like "validateImplementation()" instead of needing to pass the names of the components you want to implement. Alternatively, you could let the consumer of your CFC do the checking, or choose to not do it, thus saving the overhead -- that is, by having "implements" be just metaData information you don't force the checking but allow it to happen (using your methods in the base component) when needed. Also, why store whole instances in your __implements__ array instead of just the meta data of the components being implemented? You could save yourself having to get the metaData, and I believe that metaData is actually cached across calls, so you might actually be getting just a reference to it, thus using less memory (that is conjecture based on the behavior of changing metaData [which persists across calls to getMetaData for a given component] -- perhaps someone from MACR can enlighten us on that one). > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Davis, Eric > Sent: Wednesday, November 05, 2003 1:36 PM > To: [EMAIL PROTECTED] > Subject: [CFCDev] Holy Grail: interface/implements > > > Folks, > > As I understand it, an interface is a set of responsibilities, and an > extension is a set of capabilities. > > public class TeacherAssistant extends Student implements Teacher { > ... > } > > The TeacherAssistant *can* goToLunch(), cutClass(), and study(), but the > TeacherAssistant *must* gradePaper(), and takeRoll(). > > Attached you'll find four components and one test wrapper. > > interface.cfc: Contains one empty method that is inaccessible on its own > success.cfc: Successfully implements interface.cfc > failure.cfc: Fails to successfully implement interface.cfc > parent.cfc: Extended by success.cfc and failure.cfc, initializes the > implement() and implements() method > index.cfm: Instantiates the above components and successfully > predicts their > reactions to different types of poking. > > The main reason I put the implement() and implements() functions (better > names are always accepted) in the parent.cfc was to show that > they could be > inherited from the root component.cfc and interfaces are now indeed > possible. > > What have I gotten wrong here? I know I haven't touched properties, but > that's because I really haven't done much Java and therefore > don't know what > happens to the public, private, and protected members of the implemented > interface. > > Feedback? > > Thanks. > ecd. > > -- > Eric C. Davis > Programmer/Analyst I > Georgia Department of Transportation > Office of I.T. Applications > Web Applications Group > 404.463.2860.199 > [EMAIL PROTECTED] > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word '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]
