Re: Best way to define "private" functions
- From: dhtml <dhtmlkitchen@xxxxxxxxx>
- Date: Thu, 28 Feb 2008 12:36:52 -0800 (PST)
On Feb 28, 7:25 am, blackholebutter...@xxxxxxxxx wrote:
On Feb 28, 2:40 am, dhtml <dhtmlkitc...@xxxxxxxxx> wrote:
FunctionExpressions can be used in blocks.
So apart from blocks, in the situation where you have a simple "class"
of public and private methods, isn't it true to say that using
function declarations (for private) is less prone to error, since the
priv. function can be called from anywhere in the class, even before
the declaration whereas calling a func. created through assignments is
dependent on the assignment having previously taken place?
A function declaration does allow the function to be moved around in
source order, that is true. The errors that might be avoided -
Reference Error - would be easy to spot even with a function
expression.
function C(){
this.f = priv; // reference error.
var priv = function() { }
}
So this isn't a strong argument for choosing function declaration over
function expression.
Stylistically, I don't like having init routines in a constructor.
This could be accomplished with the module pattern, but would require
moving the object's public interface to the bottom. I find this
undesirable:
var x = (function() {
return { m : m }; // 2nd pass - Statement processed, return
// first pass, c is added to variable object with value "undefined".
var c = 23;
// first pass, m is added to the variable object as a function.
function m() {
document.title = "Aika " + c;
}
})();
x.m();
The result would be title = "Aika undefined". To fix this, you could
move the return statement to the bottom (which feels like the right
place for a return statement) --
var x = (function() {
// first pass, c is added to variable object with value "undefined".
var c = 22;
// first pass, m is added to the variable object as a function.
function m() {
document.title = "Aika " + c;
}
return { m : m }; // 2nd pass - Statement processed, return
})();
x.m();
--
But now the returned object - the one that gets assigned to x - is
described all the way at the bottom. Objects get bigger. If the return
statement is all the way at the bottom, it requires scrolling through
possibly 500+ lines just to find out what the object is about. I
prefer to see what it's about right away. It's clearer to have the
export right at the very top, so you see what the object is about
first:
var x;
(function() { // function expression
x = { m : m };
var c = 24;
function m() {
// "private" method.
function m_priv() { document.title = "Aika: " + c; }
// now assign private method as property of this.
this.m = m_priv;
return this.m();
}
})();
x.m();
Garrett
.
- Follow-Ups:
- Re: Best way to define "private" functions
- From: dhtml
- Re: Best way to define "private" functions
- References:
- Best way to define "private" functions
- From: blackholebutterfly
- Re: Best way to define "private" functions
- From: dhtml
- Re: Best way to define "private" functions
- From: dhtml
- Re: Best way to define "private" functions
- From: blackholebutterfly
- Re: Best way to define "private" functions
- From: dhtml
- Re: Best way to define "private" functions
- From: blackholebutterfly
- Best way to define "private" functions
- Prev by Date: innerHTML and grave symbol
- Next by Date: Re: block writing
- Previous by thread: Re: Best way to define "private" functions
- Next by thread: Re: Best way to define "private" functions
- Index(es):