The type checking is the most important feature, as it enables you to separate your API from it's implementation(s). Yes, CF could check your implementation against an interface at "compile-time", which means the first time that CFC is created, but that is less a desire to me as is runtime type checking. During runtime type checking, there are two options:
1) Check that a passed in CFC has the required methods to implement the interface EVERY time the method is called (SLLLLOOOOWWW) 2) Allow any CFC in the door as long as it "claims to implement" the interface (much less overhead). I think 2) is closer to the typical CF programming model (you can do bad things if you want, like not fully implement an interface). What's needed in conjunction with 2) is adjustments to the exception that occurs when you call a method that doesn't exist in a CFC. If that CFC has assumed an interface type, meaning it was passed in or returned as the interface type rather than the implementation type, then the "Method Not Found" exception that we know and love should be smart enough to say "Component X does not implement Interface Y because method Z could not be found" rather than "Method Z could not be found in Component X". I dislike when people assume the "we want interfaces" crowd wants the full-blown interface implementation that Java has... most of us know that is completely unreasonable considering the differences in the two programming models. To me it's FUD: "coldfusion is supposed to be simple, so we need to prevent these crazy java guys from making it too complex!". This causes those who don't really understand how interfaces would be used in CF to generally feel that MM shouldn't add them. The above was not directed at any specific individual, but it is something I've picked up on in the community. -Dave Ross >>> [EMAIL PROTECTED] 10/13/05 3:21 PM >>> While I agree that it isn't a compiled language in the same sense that you compile it yourself within your IDE, it is my understanding that cold fusion is itself a cf to java compiler (among other things). So the compile time checking "could" happen, but not in the same why you would see in java. At first run (compile) time the interface implementation could be checked and an error could be thrown/displayed to the page like any other CF Exception. > The real reason for wanting interfaces is for the runtime typechecking that CF does I agree this is the overall desired goal of interfaces in CF but if the interface is not enforced it becomes somewhat useless doesn't it? What good is type checking if the CFC/Object doesn't fit the description of what that type is? On 10/13/05, David Harris <[EMAIL PROTECTED]> wrote: > > I can see them.... > Heres the last post he put through... > <quote> > > > Would be nice of Macromedia would ad interfaces. > > Not for this reason. CF is not a compiled language, and the typechecking > that interfaces do happen at compile time. Bit of a catch-22, because the > checks you want HAVE to happen at a place that doesn't exist in CF's world. > > The real reason for wanting interfaces is for the runtime typechecking > that CF does. I.e. declare an interface, specify the interface as an > argument type or return type, and then pass CFCs that implement the > interface. This is a far more important reason for wanting interfaces in CF, > and fortunately, it's one that doesn't require a paradigm shift in CF > language processing to implement, so it might actually happen at some point. > > cheers, > > barneyb > > </quote> > > -----Original Message----- > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Seth MacPherson > *Sent:* Friday, 14 October 2005 8:03 a.m. > *To:* [email protected] > *Subject:* RE: [CFCDev] inheritance advice > > I haven't seen a single Barney email in a while. What's up Barney? > > - Seth > > ------------------------------ > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Roland Collins > *Sent:* Thursday, October 13, 2005 11:36 AM > *To:* [email protected] > *Subject:* RE: [CFCDev] inheritance advice > > Barney, > > All of your emails are coming through blank for me. Anyone else? > > Roland > > ------------------------------ > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Barney Boisvert > *Sent:* Thursday, October 13, 2005 2:29 PM > *To:* [email protected] > *Subject:* Re: [CFCDev] inheritance advice > > ---------------------------------------------------------- > 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 <http://www.cfczone.org/>) and > supported by CFXHosting (www.cfxhosting.com <http://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]<http://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 <http://www.cfczone.org/>) and > supported by CFXHosting (www.cfxhosting.com <http://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]<http://www.mail-archive.com/[email protected]> > > This email contains confidential information. If you are not the intended > recipient of this email, please notify Straker Interactive and delete the > email. You are not entitled to use it in any way. > ---------------------------------------------------------- > 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 <http://www.cfczone.org/>) and > supported by CFXHosting (www.cfxhosting.com <http://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]<http://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] ----------------------------------------- CONFIDENTIALITY NOTICE: This email and any attachments may contain confidential information that is protected by law and is for the sole use of the individuals or entities to which it is addressed. If you are not the intended recipient, please notify the sender by replying to this email and destroying all copies of the communication and attachments. Further use, disclosure, copying, distribution of, or reliance upon the contents of this email and attachments is strictly prohibited. To contact Albany Medical Center, or for a copy of our privacy practices, please visit us on the Internet at www.amc.edu. ---------------------------------------------------------- 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]
