On Jan 2, 9:19 am, jemptymethod <[email protected]> wrote:
> On Jan 1, 12:48 am, jemptymethod <[email protected]> wrote:
>
> > Please consider the following template. Sure its a little verbose,
> > but Uncle Bob declare comments to be failures, so I'm trying to
> > obviate such failure with the identifiers $private and $public. Also
> > the nested closures allow all state to be hidden with $private, and
> > for code (e.g. $private.init()) to be executed within the same scope
> > from which the ($public) interface is returned.
>
> > Feedback appreciated; I merely intend on opening a discussion. Some
> > or many may disagree with this approach. But is there anything
> > outright wrong about it?
It seems overly complex.
>
> Improved code formatting, with console.log un-commented, and usage of
> the module:
>
> var Module = (function() {
> var $private = (function() {
> var $state = {};
> var $private = {};
>
> $private.state = function() {return $state};
> $private.init = function() {
> console.log('$private.init invoked');
> };
>
> return $private;
> })();
or:
var $private = {
state: function(){...},
init: function(){...}
};
The use of $ may be Ok in ECMA-5, but it still grates with me. If you
want to be able to safely access "private" variables and objects, you
need privileged functions that are available externally.
>
> return (function() {
> $private.init();
> $public = {};
> return $public;
> })();
> })();
>
> var module = Module;
Which does nothing other than assign a reference to Module to module.
It doesn't execute anything, only built-in constructors can be called
that way when used with "new".
Variables starting with a capital letter are, by convention, reserved
for constructors.
--
Rob
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
