Right. As Haikal points out, the value of interfaces (and strong typing for that matter) is that it forces programmers to write more completely self-describing code. If you HAVE to specify an interface, it is easier for other programmers to understand what methods a class can implement.
Mixins are fine for individual or small team development. To scale, you need to find a way of documenting the mixins in a way that everyone in your team will agree on. I've still never had a chance to play with ColdSpring, but I'd guess you could either use a format similar to its XML to describe where to weave the mixins in (using the AOP functionality) and then whether you chose to write your own weaver, use ColdSpring's or make the XML "for reference only" would be a personal choice. If I was doing this, I'd use the XML to generate "final classes" based on the coded classes and mixins. In my experience, if code won't break if your documentation is out of date, your documentation will become out of date, so I typically make documentation functional so the code won't be generated correctly without it, thus giving all of the documentation benefits of interfaces in a language that doesn't happen to implement them natively. Come to think of it, using some simple conventions, it would probably be fairly straightforward to create an "interfaces" directory where you could code interfaces using a psuedo-Java like syntax and use that to generate the appropriate class files by mixing in the appropriate additional classes (which would be stored seperately in a mixins directory with one class per file, with file names based on the class names) either at generation time or (with a little more thought) at runtime. Think cfincludes (as per regular mixins) but with sub-include logic based on a parsing of the "interface" code. Of course, XML would be a little easier to parse . . . Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hal Helms Sent: Monday, April 03, 2006 12:05 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Mixins vs. Interfaces I'm afraid this is one of those subjects that tends to bring out the religious tendencies of developers. Some people love mixins; some love interfaces. Personally, I think they're both great; they just have different uses. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Haikal Saadh Sent: Monday, April 03, 2006 2:30 AM To: CFCDev@cfczone.org Subject: [CFCDev] Mixins vs. Interfaces I'm surprised that Vince Bonfanti's blog post on interfaces vs. mixins (http://blog.newatlanta.com/index.cfm?mode=entry&entry=F17880FB-12E2-D573-B8 81AA26B14EBCC5) hasn't gotten much of a reaction? Compared to an older post on Sean Corfield's blog (http://www.corfield.org/blog/index.cfm/do/blog.entry/entry/Interfaces_in_Co ldFusion)? Is this because we're all sick of the debate? One thing that's nagging me about Mixins is, that when working on a complex application with a good sized team, it becomes hard to determine why (or even when :( ) an object possesses certain operatons. I mean, in Java, if you have: public class Duck implements Fryable, Throwable, Serializable{} It's evident that someone needs to fry a duck, have a ballistic duck, and a transmit a duck down a wire (Whether it's over IP or sneakernet or whether it's flies is largely irrelevant at this point, but you can count on it to be transmitted when the need comes). Whereas with mixins, at some stages you have a comatose duck, a fryable duck, and a flameproof duck, an unliftable duck, and duck that's too fat to fit into a wire. Maybe it's because I know java, and have not much to do with Ruby apart from a RoR Hello World, but I have a feeling that I'm missing a point? And what about the mention that the next release of BD will have CFC interface support? And the rumours at WebDU that CF8 will have interfaces as well? -- Haikal Saadh, Applications Programmer Teaching and Learning Support Services K405, Queensland University of Technology, Kelvin Grove Campus [EMAIL PROTECTED], 3864 8633 CRICOS No. 00213J ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
