Giving My ColdFusion Components And My JavaScript Components The Same Structure

This is very similar to how I was taught to write C++ objects, though you'd usually have just the declarations in the header file and the definitions in a source file. Since you don't tend to have that separation of declaration from definition in ColdFusion or JavaScript, you have both the declaration and definition in one place. (Code-folding comes in really handy.)

I've found that, as I've gotten more familiar with ColdFusion and JavaScript, I've started emulating some of the coding patterns I learned in C++. By having the constructors and public functions at the top, the interface gets priority. The rest is only for those who want a look under the hood.

Some might have a knee-jerk response: "This is ColdFusion, not C++. Quit trying to turn it into something it isn't!" We aren't trying to turn ColdFusion into C++; we're simply applying the lessons we've learned over the decades in other languages to this one. He who can't learn his lessons from other languages is doomed to repeat them in his language of choice.

Pretty much how I do my stuff, tho I omit the cfscript tag and use pure script components.

hmmm, I do however use annotations to clean up my method declarations (which railo stupi-- stubbornly does not support last I looked)

ex:

/**
* @output false
* @accessors true
* @ExtDirect true
*/
component foo extends bar {

/**
* @getter true
* @setter false
*/
property string a;

variables.a = '';

/**
* @output false
*/
public any function init(){
return this;
}

/**
* @output false
* @roles "admin,poweruser,coolguys"
* @ExtDirect true
* @RequiresCSRF true
*/
public void function doThing( required string txt="" ){
variables.a = arguments.txt;
}
}

The annotations are code folded up and out of the way, leaving a nice clean method declaration with the truly important parts visible, ex:

/**...
public void function doThing( required string txt="" ){}

-Jim

The memory and performance penalties for working around prototypical conventions are more pronounced than you let on in this post. In particular on the v8 engine used in Chrome, this approach would also negate the memory lookup and management gains the engine provides through its 'hidden class' mechanism.

http://thibaultlaurens.github.io/javascript/2013/04/29/how-the-v8-engine-works/

Context is important, as only dealing with a handful of Friend objects at one time would probably not produce much in the way of poor behavior, but this approach puts a significantly lower performance ceiling on your application should you have even a single function of the scale that it would need several hundreds or thousands of Friends simultaneously in memory.

I don't think that, in the vast majority of contexts, the gain in consistent code aesthetics with indirectly related backend code, which is admittedly a pretty subjective value, is worth taking on the resulting performance constrictions where it really counts: in the experience for your end user. I'd suggest rethinking your advocacy of this approach.

@Ben,

This jsbin illustrates two major reasons why following prototypical patterns should be preferred in all but the most specialized of special scenarios:

http://jsbin.com/oKUzowo/4/edit (Open the console tab at top, and then reload to see what the script logs.)

The biggest gain in memory usage and management can be seen here; this is the reasoning underlying the 'reference good/re-creation bad' mantra. Implementing a 'revealing module' pattern in javascript, while it performs the task of information hiding quite well, does so at a significant performance and memory expense that increases in a linear fashion with the size of the object's definition, and then linearly again with the spin-up of more instances.

Each instance of the original Friend above hoists it's own copy of every method included inside; that they're functionally identical is irrelevant to the runtime, getFirstName in one Friend is completely different than the getFirstName in another Friend, having their own separate addresses and spaces in memory.

A prototypically-constructed object, like protoFriend in the jsbin, instead will hoist that function into memory once and reference it at that position thereafter. This makes new object spin-up faster, as it doesn't have to hoist the entire object and all its methods again, and it makes using that new object faster, as it doesn't have to wastefully pull up identical functions stored in many different places across memory.

An ancillary point, but terrifically important in some contexts, is that instances created from a 'revealing module' pattern have no inherent connection with each other as objects of a particular type unless you explicitly bake that functionality back in somehow. In short, it breaks the native`instanceof` functionality, as what returns is nothing but an instance of `Object` and not `Friend` as might be expected. This is also illustrated in the jsbin above.

That JS doesn't have natively the ability to denote variables and methods as private is a bit of a drawback, especially if you've grown accustomed to those protections being there, but I'd argue against short-circuiting other core features of the language to get JS to behave in a similar manner, especially when those bits are central to performance and memory management.

Thanks for the conversation. :)

For scoping demonstration purposes only (in other words, the logic doesn't make sense in this example), If I had:

component {
Variables.X = 1;
 
function Junction(X) {
local.X = arguments.X;
}
}
 
Y = new myComponent().Junction(2);

Then I would similarly scope variables in JavaScript like this:

(function() {
var Variables = {};
Variables.X = 1;
function Junction(X) {
	var local = {};
	local.X = X;
}
$(document).on('click','#myID',Junction(2));
})();