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?

Some people wonder why there is an output option in the CFCOMPONENT and CFFUNCTION tags. They see no reason to use it, let alone set it to false. I'll give you a perfect reason.
Formatting
I was writing an auto-scheduled RSS feeder for a client and I had to use a function that I wrote a while back from another CFC. It had to do with some really effective SEO formatting for the feed. The problem was that ever time I ran the function to alter a piece of text to make it 'legal', it put in an extra space. I had no clue where it was coming from or why and because it was in an URL, there was a problem. After looking all over and testing each piece of code, I found that the formatting function didn't have an output argument. Putting one in made the formatting work exactly as it should have.
So next time your pulling your hair out over some strange space, remember my words. Look to the output argument first.

I was showing some code off to Sean last week and he looked at it and was rather upset. He claimed that it used a side effect to do its job and was bad programming. I promised to think about it and I did. I disagree.

The code was a method for use within a CFC that would handle all of the caching needed for the CFC. It would check if the CFC was cached under a specific name in a specific memory scope and if not, it would cache it. Basically a one stop shop caching.

It worked by passing a reference to the memory scope where the CFC was to be cached into the CFC method. As all structures are passed by reference, I could then alter the structure inside the CFC method without returning anything.

Now to understand the argument, I should define what a side effect is. Here's what Wikipedia says:

"In computer science, a function is said to produce a side-effect if it modifies some state other than its return value. For example, a function might modify a global or "static" variable, modify one of its arguments, write data to a display or file, or read some data from other side-effecting functions."

Basically, a side effect is any operation that modifies some state other than its return value. Hm. So adding, editing or deleting data from a DB without returning any data or returning only a success value would be considered a side effect. Sending mail from a CFC is considered a side effect. There's a TON of CF stuff that would be considered a side effect so he must not be talking about that. Maybe he was talking about having a CFC alter a memory variable without returning a reference to that variable. That sounds likely.

Bottom line is that I learnt a new phrase, thought over my approach and have decided that a single method for caching that can be used in any CFC at any time is worth it. I'll have a writeup on my thinking up to the creation of the CFC and its code soon.

BTW, the act of storing a CFC in a memory variable is Cachine, not Persistance. If you disagree, argue with Sean about it here:
Persistence