I think have to agree with Tanguy "language envy" has crept in. If you want interfaces and nulls there's always ASP.NET or BlueDragon.NET which give you full access to C#.
So how about them, there Star Wars, eh? Ready to change the subject, - Seth -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RADEMAKERS Tanguy Sent: Thursday, May 19, 2005 2:23 PM To: [email protected] Subject: RE: [CFCDev] Interfaces (was Null values) joining late with my two bits. You could already implement "poor man's interfaces" yourself by using wrapper CFCs that delegate method calls to their inner CFCs. Consider this example: ---------------------snip: a.cfc------------------------------- <cfcomponent name="a"> <cffunction name="doFoo" access="public" output="false" returntype="string"> <cfreturn "this is a.cfc doing the foo"/> </cffunction> <cffunction name="doBar" access="public" output="false" returntype="string"> <cfreturn "this is a.cfc doing the bar"/> </cffunction> </cfcomponent> ---------------------snip: b.cfc------------------------------- <cfcomponent name="b"> <cffunction name="doFoo" access="public" output="false" returntype="string"> <cfreturn "this is b.cfc doing the foo"/> </cffunction> <cffunction name="doBar" access="public" output="false" returntype="string"> <cfreturn "this is b.cfc doing the bar"/> </cffunction> </cfcomponent> ---------------------snip: interface.cfc----------------------- <cfcomponent name="interface"> <!--- this is the inner CfC ---> <cfset variables.innerCfC = ""> <!--- pseudo-constructor ---> <cffunction name="init" output="false" returntype="void" access="public"> <cfargument name="wrappedCfC" type="WEB-INF.cftags.component"> <cfset variables.innerCfC = arguments.wrappedCfC> </cffunction> <!--- these are the interfaced methods ---> <cffunction name="doFoo" access="public" output="false" returntype="string"> <cfreturn variables.innerCfC.doFoo() /> </cffunction> <cffunction name="doBar" access="public" output="false" returntype="string"> <cfreturn variables.innerCfC.doBar() /> </cffunction> </cfcomponent> ---------------------snip: test.cfm---------------------------- <cfscript> Iface1 = CreateObject("component","interface"); a = CreateObject("component","a"); IFace1.init(a); Iface2 = CreateObject("component","interface"); b = CreateObject("component","b"); IFace2.init(b); </cfscript> <cfdump var="#IFace1#"> <cfoutput> #IFace1.doFoo()# <br /> #IFace1.doBar()# <br /> </cfoutput> <cfdump var="#IFace2#"> <cfoutput> #IFace2.doFoo()# <br /> #IFace2.doBar()# </cfoutput> ---------------------END--------------------------------------- Here i'm making the a and b objects myself because it's a short example, but i could just as well be returning them from somewhere else (say a factory method) - in which case i could specify that that method returns instances of "interface.cfc" instead of "any". As far as the calling code knows, the instances IFace1 and IFace2 are of the same type (well, they are). But the other nice thing about interfaces is that they act as a kind of design contract. In the example above, there's nothing to stop me from passing a CFC instance that doesn't have doFoo() or doBar() methods to IFace1 or IFace2 and i wouldn't know about it until i tried to call the method. In a compiled language like java you'd never get that far because you would get an error when you built your class. There's another "poor man's solution" for CF which would be based on having interface.cfc check whether the wrapped CFC implements all the methods it (interface.cfc) does (using calls to getMetaData(this) and getMetaData(variables.innerCfC), along with some struct manipulation... check out getComponentProps() by Robby Lansaw on cflib.org for a good place to start), and throw an exception if it didn't (sorry, that CFC isn't allowed to implement me). This is still a runtime error, but it will be thrown irrespective of whether or not the missing method is called, so you stand a slightly higher chance of noticing it... One obvious strategy is to define a baseInterface.cfc class with the constructor (including checking code) and have interface.cfc extend it - leaving only the methods (doFoo and doBar) to be defined in interface.cfc Personally, i'm not sure i'm convinced about a real need for interfaces in CF. I think a tiny number of users would find them truely useful and the rest are just suffering from language envy (caused by reading too many patterns books). ColdFusion is simple. I like simple. Simple is good. But that's just me: pissing on the shoes of giants ;) /t ---------------------------------------------------------- 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
