This is a realization that has been thrust upon me over the years. I belong to the wrong ColdFusion religion. My religion is that ColdFusion was designed for clean, understandable applications written in a quick and easy style by people of all levels of programming skills. This is NOT the current religion of Frameworks and OOP.

I was burnt a while back when daring to suggest that a framework could be altered to fit a client. I see that I was right then and I feel I'm still right now. I'll use a framework when it's required and will only use parts when they're required. I'll use OOP when it's required and only parts when they're required. I'm not going to accept the dogma that says that frameworks and OOP are the one, true way to go.

And the new golden child, ORM? Well I'll use it when it looks right for a project and reject it when not. And when (not if) this opinion gets people upset, well...too bad.

Yes, the above is a rant and one that's been sitting in reserve for years. It was true then and is even more true now.

I was doing a remote presentation last night on "Object Orienter Programming for ColdFusion Developers" and it eventually moved over to the topic of optimizing ColdFusion Components. While I was showing what I do for speed, I relayed a story about a client of mine who is using Mach II. I was brought in to speed up the clients site which was timing out on a regular basis.

After a review, I found some places that could be optimized and one major place was the Mach II code. I rebuilt most of it and the time savings was immense. Of course, in order to make it faster I had to cheat and break many of the accepted 'rules' of OOP and CFCs. Not something that I suggest anyone doing without a full understanding of the how and why of it (which I'll talk about another time).

After telling the story and showing what I did, someone assumed that I did not like Mach II and asked what Framework I used. I quickly corrected his conclusion and told him not only do I have nothing against Mach II, but it's a really well thought out and solid framework. I don't use it because I don't use any of the public frameworks. I'm obsessed with optimizing my code for speed and performance and really optimal code doesn't go hand in hand with frameworks. On the other hand, I stressed that using a framework is a MUST in almost all situations and that people should not go my route unless they really know what they're doing and have very strict control over who has access to their code.

Yep, the second issue of the Fusion Authority Quarterly Update is not only in my hand, it's packed and ready to go to all subscribers. But of course, anyone who subscribes before the end of the year gets this issue as well as the previous one in PDF format as well. Trust me, PDF is nice to read once in a while, but nothing beats the solid feel of this journal.

As for content, we're talking an actual book worth of Object Oriented Programming for ColdFusion as well as Frameworks. 120 pages of it to be exact (20 pages over what we expected for this issue). But why listen to me when the table of contents speaks for itself:

Editorial

OOP in Your Toolbox

by Judith Dinowitz

Columns

What's Hot? What's Not?

by Raymond Camden, Simeon Bateman, Charlie Arehart, Kurt Wiersma, Michael Dinowitz

Tipical Charlie - How do I Call Thee (CFC)? Let Me Count the Ways!

by Charlie Arehart

Features

Object-Oriented Programming: Why Bother?

by Brian Kotek

The Object-Oriented Lexicon

by Hal Helms

Design Pattern Safari

by Peter J. Farrell

From User-Defined Functions to ColdFusion Components

by Michael Dinowitz

Base Classes: Better Than Your Knew!

by Peter Bell

Concepts

Introduction to Frameworks

by Jared Rypka-Hauer

Fusebox 5 Fundamentals

by Sean Corfield

Mach-II Fundamentals

by Matt Woodward

Model-Glue Fundamentals

by Joe Rinehart

Lessons I Learned from My First Model-Glue Application

by Jeffry Houser

ColdSpring Fundamentals

by Chris Scott

Reactor Fundamentals

by Doug Hughes

Tools

FusionDebug Explained: Interactive Step Debugging for CFML

by Charlie Arehart

And no, we're not going to kill you with advertising. We don't even have advertisers. What we have are supporters who are helping to make sure that we can get the journal to you. A big thanks to:

Adobe Systems, inc. - Makers of ColdFusion, Flex and much, much more

Intergral Information Systems - makers of Fusion-Reactor and Fusion-Debug

WebApper Services, LLC- Makers of SeeFusion

Quill Design - Maker of the SiteDirector shopping system

Straker Interactive - Makers of ZoomFlex

Liquid Image Studios - More creative design than you can shake a forest at

House of Fusion - Providers of quality ColdFusion and related technical content

You can order the journal right away and we'll not only get it to you ASAP but we'll give you access to a PDF of it to hold you over.

http://www.fusionauthority.com/quarterly

We accept orders through Google Checkout (USA Only - Preferred method), Paypal (World wide), or contact us for bulk orders and we'll work with you.

I've been watching people talk back and forth about including interfaces into the ColdFusion language or not and I've been wondering why bother. From what I know, interfaces (the Java keyword rather than the general term) are used to define what is basically a "rules class". This rules class contains the names of methods and any arguments that they may need. Any class that uses this rules class (implements it), must have a method within it of the same name (and arguments) or else an error will be thrown.

Basically an interface is a contract between a class and a rules class that says that the class has to have all of the rules' methods to be legal.

In ColdFusion terms, this means that there is a 'rules' component (an interface component) that only contains cffunction tags. The cffunction tags can have cfargument tags, but these are not required. Nothing else can be in this component other than these functions.

Some other component will include this interface component and basically have to create a function for each of the functions in the interface component. How this will be done is all theory to the community at the moment, but the theory will follow the steps above.

Now if my definition is correct, then this sounds more like something that would be useful at development time to make sure that a component being written follows certain rules. If it's going to be used at runtime, then it 'feels' like it would just be more overhead and unneeded validation. Am I wrong? Is there something I'm missing here? What are the issues and why should I (or anyone else) care?

You know, duck typing is really easy. It's a simple concept for a simple job. Do you know why it's so hard for people to learn it? Do you know why it took me so long to understand it? Because it's a simple concept hiding behind a stupid phrase. Walks like a duck, talks like a duck, acts like a duck. Flock the duck! Really - Remove the stupid phrase and the stupid euphemism and what you get is something that's really easy to understand.

So what is duck typing? Duck typing is a concept where you pass an object reference, and only an object reference, into a CFC. It has nothing to do with variables; it has to do with object references.

Inside the CFC, you're going to have some code that's going to make use of an object reference that's been passed in. You can pass in 10 different object references, and as long as they have the same method that the CFC is going to be making use of, then it's duck typing.

So let's do a really simple example. Let's say you have a CFC that's trying to make use of the FlocktheDuck() method. You can pass in a reference to the orangeduck CFC that contains FlocktheDuck(). You can pass in a reference to the mallardduck CFC that contains a FlocktheDuck() method. You can pass in a reference to the rubberduck CFC, as long as it contains a FlocktheDuck() method. As long as these references that you are passing in contains the FlocktheDuck() method, then the CFC that you're passing them into will use the FlocktheDuck() method, and that's Duck Typing. What the FlocktheDuck() method actually does depends on the object reference being passed in - and we don't care what it is! Because it's all the same method name using the same method variables. What it returns we also don't care about, because it's going to return something. But it has the same method name and the same method arguments.

That's it. Simple. To the point. Now all you have to do is hide it behind a stupid phrase, and no one knows what you're talking about.