http://wilq32.googlepages.com/wilq32.class

http://wiki.s2807.gridserver.com/JavascriptTechnique is the code.

Closures are powerful, useful, yes. Necessary here? hardly.

Knowing when not to use one is as important as knowing what a closure is.

>It can keep the global name space less cluttered.
Singleton (and this bastardized version) does little to keep the global namespace clean, though this is not really relevant to the javascript/web-paradigm, where there is library code and implementation code.

In fact, if your main goal is to keep the global nameppace clean, use a just
create one approach (hardly necessary for most JS).

There is a much better way to write a Singleton using lazy-load approach and enforcing an entryPoint to the constructor.

One more problem with the “power constructor”: There is extra memory allocation and worse performance due to closed scope. References to inner function objects are assigned to to the public properties of a constructed object.

Closures should be used where they are needed and ONLY where they are needed. For example: event registry/broadcast adapter/change manager/notification system, or adding advice (not generally recommended). Closure is hardly necessary here.

I think that in many cases design patterns are exactly to add in “missing” features of a language. For example, Smalltalk classes all inherit from a class with Subject and Observer interfaces. Perl has modules and exporting like the pattern described here. C++ has template classes. Java has interfaces. JavaScript has prototype-based inheritance. All of these concepts could be useful at some point in another language where it is missing. People were using classes and inheritance in C before any object-oriented language had sugar for class definition.

I agree that this module pattern in JavaScript can be gratuitous at times. It doesn’t create indestructible objects with truly private/protected anything. It can keep the global name space less cluttered. It also teaches the idea of closure and automatically evaluated functions which is very useful. I use it relatively frequently when working around browser issues to produce efficient functions that don’t determine the browser-appropriate algorithm each time a function is called.

It is all subjective.

Actually I am an advocate of design patterns. However patterns are not designed to conceptualise missing features of a language, rather allow developers to communicate using well-known, well understood constructs for software interactions.

I realise I am being ambigious and perhaps what I have just said would back up the pattern used above.

My issue with this pattern is that it’s gratuitous. Patterns for the sake of patterns are bad because they add an unnessecary level of abstraction which only reduces maintainability further.

I guess this is pretty subjective so don’t take this as a statement, rather my opinion on the matter.

Tim

An untyped object with an anonymous constructor.

YUI loves anonymous functions and I don’t know why. It is a real pain in the neck to debug “anonymous” or “no name” in the debugger.

Now please look at the code and notice that the object’s public interface is returned. All the “public” members are at the very bottom. Is this not completely backwards?

This is Doug’s “power constructor” renamed. Doug is a nice man and I don’t hate him. It is not a good practice.

The way to enforce an entryPoint is with Function.prototype.caller. This is not very hard to do and makes a private constructor, lazy-load singleton possible.

Opera chooses to support wacky css instead of critical properties like Function.prototype.caller. Opera should fix this bug. Ian, Anne…

Function.prototype.caller can also be used to debug errors, and even build-your-own error stack by looking up the call chain. (Error.stack is natively supported in FireFox and Webkit)

Yes, Dustin, a lot of people at Yahoo do in fact use that approach and I am sure that it came from Doug. I have tried to explain my best why it is not good. I hope it makes sense to others.

This is meant to be a singleton pattern.