Comments on: Why Interfaces In ColdFusion Are Irrelevant http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/ devnulled provides news, tips, resources, and articles about various topics that software developers and engineers enjoy. Sun, 23 Nov 2008 12:08:03 +0000 http://wordpress.org/?v=abc By: Brandon Harper http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26489 Brandon Harper Thu, 12 Oct 2006 05:15:05 +0000 http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26489 @Vince To me an interface gets a varying, loose definition when dealing with a dynamically typed language. For instance, I've seen at least a couple of proposals for interfaces in Python (which has been around just a little bit longer than CF) but none of them have ever been approved because there are such a large gaps between different people's interpretations of what an interface should do in a dynamic language, its syntax, etc. I can understand the slight boost in productivity in implementing an interface tag vs. the code example I used, but otherwise it just seems like a difference in semantics as the functionality is fairly similar as there isn't a way to always ensure a method is going to accept/return what you expect. I guess it seems more like a template to me? Granted, I haven't looked at how it's implemented in BD 7 at this point. @JAlpino Good point. I do wish CFC's supported some sort of import statement as other dynamic languages do. It kind of sucks having to have various objects created instead of just including them with objects that you use them in; in particular utility type components. @Vince

To me an interface gets a varying, loose definition when dealing with a dynamically typed language. For instance, I’ve seen at least a couple of proposals for interfaces in Python (which has been around just a little bit longer than CF) but none of them have ever been approved because there are such a large gaps between different people’s interpretations of what an interface should do in a dynamic language, its syntax, etc.

I can understand the slight boost in productivity in implementing an interface tag vs. the code example I used, but otherwise it just seems like a difference in semantics as the functionality is fairly similar as there isn’t a way to always ensure a method is going to accept/return what you expect. I guess it seems more like a template to me? Granted, I haven’t looked at how it’s implemented in BD 7 at this point.

@JAlpino

Good point. I do wish CFC’s supported some sort of import statement as other dynamic languages do. It kind of sucks having to have various objects created instead of just including them with objects that you use them in; in particular utility type components.

]]> By: JAlpino http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26432 JAlpino Wed, 11 Oct 2006 23:07:59 +0000 http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26432 One benefit of having interfaces in CF that no one seems to have touched on is the fact that they would allow us to extend our components with multiple other components, beyond the single inheritance option we currently have. Sure you could use mixins to add multiple behaviors to another component but I feel it's a very non-oo solution to solving that problem. What happens if I wanted to introspect my duck component to see if it's quackable? One benefit of having interfaces in CF that no one seems to have touched on is the fact that they would allow us to extend our components with multiple other components, beyond the single inheritance option we currently have. Sure you could use mixins to add multiple behaviors to another component but I feel it’s a very non-oo solution to solving that problem. What happens if I wanted to introspect my duck component to see if it’s quackable?

]]> By: Vince Bonfanti http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26388 Vince Bonfanti Wed, 11 Oct 2006 17:46:15 +0000 http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26388 I meant to say, "it's not possible to check the entire method signature when the CFC is created, only the method name." I meant to say, “it’s not possible to check the entire method signature when the CFC is created, only the method name.”

]]> By: Vince Bonfanti http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26387 Vince Bonfanti Wed, 11 Oct 2006 17:45:31 +0000 http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26387 You're correct, it's not possible to check the entire method signature when the CFC is created, only the signature name. (By the way, this is consistent with the way it works when you override a CFC super-class method: the override is based only on the method name, not the entire signature as it is in Java.) So it's not perfect, but I wouldn't consider that an argument against interfaces. I'm drafting a blog entry entitled, "Always Specify Argument and Return Types, and Why Interfaces Are Good" to address these questions, because I think there are a lot of misperceptions and misinformation out there. Unfortunately, I do have a day job, so completing that blog entry may take a few more days... You’re correct, it’s not possible to check the entire method signature when the CFC is created, only the signature name. (By the way, this is consistent with the way it works when you override a CFC super-class method: the override is based only on the method name, not the entire signature as it is in Java.) So it’s not perfect, but I wouldn’t consider that an argument against interfaces.

I’m drafting a blog entry entitled, “Always Specify Argument and Return Types, and Why Interfaces Are Good” to address these questions, because I think there are a lot of misperceptions and misinformation out there. Unfortunately, I do have a day job, so completing that blog entry may take a few more days…

]]> By: Brandon Harper http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26382 Brandon Harper Wed, 11 Oct 2006 16:57:38 +0000 http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26382 Hmm, there are a couple of errors in that code compared to what I typed and I'm not sure why.. must be a problem with the code formatter I'm using. Anyhow, excuse any obvious problems (ie.. missing a cffunction close tag). Hmm, there are a couple of errors in that code compared to what I typed and I’m not sure why.. must be a problem with the code formatter I’m using. Anyhow, excuse any obvious problems (ie.. missing a cffunction close tag).

]]> By: Brandon Harper http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26381 Brandon Harper Wed, 11 Oct 2006 16:50:05 +0000 http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26381 Part of the interface contract in Java is method signatures; you know what data types will be returned, not just that the methods exist. It sounds like BlueDragon just checks to make sure that a given method is implemented? I'm not sure how it would be able to catch data type errors at compile time.. i.e., something returned a string instead of an object. Because of the nature of dynamic languages, there is not a way the compiler can check to ensure a given method will return what you expect. Here is a poorly and quickly hacked together example (and I'm just making up some cfinterface syntax as I haven't used BD 7.0) which is coded for brevity, but: Fooable.cfc [code] <cfinterface> <cffunction name="getInt" returntype="numeric" /> <cffunction name="isRunning" returntype="string" /> </cfinterface> [/code] Foo.cfc [code] <cfcomponent interface="Fooable"> <cffunction name="init" returntype="any"> <cfset Variables.Bar = CreateObject("Bar").init() /> <cfreturn this /> </cffunction> <cffunction name="getInt" returntype="numeric" /> <cfreturn Variables.Bar.getData() /> <cffunction name="isRunning" returntype="boolean"> <cfreturn Variables.Bar.returnSelf().isRunning() /> </cffunction> </cfcomponent> [/code] Bar.cfc [code] <cfcomponent> <cffunction name="init" returntype="any"> <cfreturn this /> </cffunction> <cffunction name="getData" returntype="numeric" /> <cfset var randNum = RandRange(1, 4) /> <cfset retValue = "" /> <cfswitch expression="#randNum#"> <cfcase value="1"> <cfset retValue = "This is not numeric" /> </cfcase> <cfcase value="2"> <cfset retValue = StructNew() /> </cfcase> <cfcase value="3"> <cfreturn this /> </cfcase> <cfcase value="4"> <cfreturn 123 /> </cfcase> <cfcase value="5"> <cfreturn true /> </cfcase> </cfswitch> <cfreturn /> <cffunction name="returnSelf" type="any"> <cfreturn getData() /> </cffunction> <cffunction name="isActive" returntype="boolean"> <cfreturn getData() /> </cffunction> </cfcomponent> [/code] There are several obvious problems here that compile time checking of a dynamic language can't check. Because the compiler can't restrict what you use a given variable for, the method getInt() will compile but will throw runtime errors each time it is called because the interface can't ensure that a value of numeric will be returned. While you can dictate that methods be defined, there isn't a way to make them follow the contract of what they should return at compile time. This is not the best example, but it's what I can come-up with without detracting myself from work for too long. Vince-- what would happen in BD with code similar to this? Also, can you invoke interfaces as an object or do they act the same as interfaces in Java? Part of the interface contract in Java is method signatures; you know what data types will be returned, not just that the methods exist. It sounds like BlueDragon just checks to make sure that a given method is implemented? I'm not sure how it would be able to catch data type errors at compile time.. i.e., something returned a string instead of an object.

Because of the nature of dynamic languages, there is not a way the compiler can check to ensure a given method will return what you expect. Here is a poorly and quickly hacked together example (and I'm just making up some cfinterface syntax as I haven't used BD 7.0) which is coded for brevity, but:

Fooable.cfc

PLAIN TEXT
CODE:
  1. <cfinterface>
  2.  
  3.     <cffunction name="getInt" returntype="numeric" />
  4.    
  5.     <cffunction name="isRunning" returntype="string" />
  6.    
  7. </cfinterface>

Foo.cfc

PLAIN TEXT
CODE:
  1. <cfcomponent interface="Fooable">
  2.    
  3.     <cffunction name="init" returntype="any">
  4.         <cfset Variables.Bar = CreateObject("Bar").init() />
  5.         <cfreturn this />
  6.     </cffunction>
  7.  
  8.     <cffunction name="getInt" returntype="numeric" />
  9.         <cfreturn Variables.Bar.getData() />
  10.    
  11.    
  12.     <cffunction name="isRunning" returntype="boolean">
  13.         <cfreturn Variables.Bar.returnSelf().isRunning() />
  14.     </cffunction>
  15.  
  16. </cfcomponent>

Bar.cfc

PLAIN TEXT
CODE:
  1. <cfcomponent>
  2.  
  3.     <cffunction name="init" returntype="any">
  4.         <cfreturn this />
  5.     </cffunction>
  6.    
  7.     <cffunction name="getData" returntype="numeric" />
  8.         <cfset var randNum = RandRange(1, 4) />
  9.         <cfset retValue = "" />
  10.        
  11.         <cfswitch expression="#randNum#">
  12.             <cfcase value="1">
  13.                 <cfset retValue = "This is not numeric" />
  14.             </cfcase>
  15.             <cfcase value="2">
  16.                 <cfset retValue = StructNew() />
  17.             </cfcase>
  18.             <cfcase value="3">
  19.                 <cfreturn this />
  20.             </cfcase>
  21.             <cfcase value="4">
  22.                 <cfreturn 123 />
  23.             </cfcase>
  24.             <cfcase value="5">
  25.                 <cfreturn true />
  26.             </cfcase>
  27.         </cfswitch>
  28.        
  29.         <cfreturn />
  30.    
  31.    
  32.     <cffunction name="returnSelf" type="any">
  33.         <cfreturn getData() />
  34.     </cffunction>
  35.    
  36.     <cffunction name="isActive" returntype="boolean">
  37.         <cfreturn getData() />
  38.     </cffunction>
  39.    
  40. </cfcomponent>

There are several obvious problems here that compile time checking of a dynamic language can't check. Because the compiler can't restrict what you use a given variable for, the method getInt() will compile but will throw runtime errors each time it is called because the interface can't ensure that a value of numeric will be returned.

While you can dictate that methods be defined, there isn't a way to make them follow the contract of what they should return at compile time. This is not the best example, but it's what I can come-up with without detracting myself from work for too long.

Vince-- what would happen in BD with code similar to this? Also, can you invoke interfaces as an object or do they act the same as interfaces in Java?

]]> By: Vince Bonfanti http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26337 Vince Bonfanti Wed, 11 Oct 2006 12:37:27 +0000 http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26337 "In Java, one of the advantages to using an interface is that it does compile time checking to make sure that classes implementing interfaces follow the contract dictated by the interface. Since ColdFusion is a dynamic language, there really isn't a good way to do compile time checking of interfaces, so it would be a pointless endeavor." The second part of this statement isn't really accurate. In the BlueDragon 7.0 implementation of CFC interfaces (and abstract CFCs), the check is make at the time a CFC is created using CFOBJECT or CreateObject to make sure it implements the required functions as dictated by the interfaces. While not as "early" as a compile-time check, it's still better than not getting a runtime error until you actually try to invoke a method that isn't implemented (such as what happens with "duck typing"). "In Java, one of the advantages to using an interface is that it does compile time checking to make sure that classes implementing interfaces follow the contract dictated by the interface. Since ColdFusion is a dynamic language, there really isn't a good way to do compile time checking of interfaces, so it would be a pointless endeavor."

The second part of this statement isn't really accurate. In the BlueDragon 7.0 implementation of CFC interfaces (and abstract CFCs), the check is make at the time a CFC is created using CFOBJECT or CreateObject to make sure it implements the required functions as dictated by the interfaces.

While not as "early" as a compile-time check, it's still better than not getting a runtime error until you actually try to invoke a method that isn't implemented (such as what happens with "duck typing").

]]> By: Tom Chiverton http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26306 Tom Chiverton Wed, 11 Oct 2006 08:47:52 +0000 http://devnulled.com/content/2006/10/why-interfaces-in-coldfusion-are-irrelevant/#comment-26306 "the implementation of interfaces in ColdFusion would not prevent someone from breaking the contract of an interface before runtime" I'm still not sure how you got to that conclusion - a proper interface implementation *would* prevent you from not implementing everything you should by throwing a compile-time error (at first run of the CFC). "the implementation of interfaces in ColdFusion would not prevent someone from breaking the contract of an interface before runtime"
I'm still not sure how you got to that conclusion - a proper interface implementation *would* prevent you from not implementing everything you should by throwing a compile-time error (at first run of the CFC).

]]>