By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,728 Members | 2,414 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,728 IT Pros & Developers. It's quick & easy.

Simpleton singleton that installs its own function type properties

P: n/a
foo() generates elements with event handlers that invoke foo function
properties.

Is this an abhorrent or misthought pattern ?
It allows just the one occurence of identifier /foo/ to be changed to
/whatever/ when need arises and everything should still work.

function foo () {
var callee = arguments.callee
if (callee.singleton != undefined)
return callee.singleton

if (this == window)
return new callee(arguments)

installClassFunctions()

callee.singleton = this
return

function installClassFunctions() {
callee.classMethod1 = function () {alert('1')} // global function but
property of foo
callee.classMethod2 = function () {alert('2')}
}
}

foo()
foo.classMethod1() // not normally invoked directly, verifies operation

Even though foo is singleton, the handlers (in question) would have to be
passed a global reference to the singleton instance (if the classMethods
were programmed to be instance of foo properties. (Also, no sense in
prototyping singleton methods)

--
Richard A. DeVenezia
Jul 20 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
"Richard A. DeVenezia" <ra******@ix.netcom.com> wrote in message
news:bj************@ID-168040.news.uni-berlin.de...
foo() generates elements with event handlers that invoke
foo function properties.
Not in this code it doesn't.
Is this an abhorrent or misthought pattern ?
How well any given pattern fits the situation it is going to be used in
depends a lot on what it is intended to achieve. As your script does
nothing concrete it is difficult to say whether it is the best way of
going about it (beyond the trivial observation that the best way of
doing nothing is not to write any code ;-)
It allows just the one occurence of identifier /foo/ to be changed
to /whatever/ when need arises and everything should still work.
Referring to - arguments.calee - seems reasonable way of referring to
the constructor anonymously. But is the ability to change the identifier
for the constructor without having to do a search and replace on the
rest of the code is important then there are other ways of achieving
that.
function foo () {
var callee = arguments.callee

if (callee.singleton != undefined)
return callee.singleton

if (this == window)
return new callee(arguments)

installClassFunctions()

callee.singleton = this
return

function installClassFunctions() {
callee.classMethod1 = function () {alert('1')} // global function butproperty of foo
With newsgroup postings it is often worth looking at your newsreader
software's line wrapping settings (mine is set at 72 characters, for
example) and pre-wrapping source code so that it will not be split
across lines in undesirable places. JavaScript is very tolerant of the
insertion of white space characters.
callee.classMethod2 = function () {alert('2')}
}
}

foo()
foo.classMethod1() // not normally invoked directly, verifies operation
Bear in mind that in a function invoked as a method of a function the -
this - keyword becomes a reference to the function that the invoked
function is a method of..
Even though foo is singleton, the handlers (in question) would have to
be passed a global reference to the singleton instance (if the
classMethods were programmed to be instance of foo properties.
As it stands this singleton pattern is one perfectly good approach.
There are at least half a dozen alternatives and this one would not be
my first choice of them. But my choice would be influenced most by those
event handlers that you did not include. How they are assigned, what
they do, what they need to refer to and so on.
(Also, no sense in prototyping singleton methods)


There may be some sense in it (the prototype object exist after all), or
assigning the methods directly to properties of the one object when
constructed. But if the singleton is only interested in event handlers
does it need a public interface at all? One of the main issues with
assigning inner functions to event handlers is the duplication of
function objects; that is not going to be an issue with a singleton.
(There is also the IE memory leak issue but that can be avoided with
care.)

The hypothetical discussion of coding patterns is one thing but there
comes a point where code is written to address a requirement. Your
requirement seems to include a desire to make the singleton "class"
independent of the identifier for its constructor, but in addition you
have associated requirements in connection with these event handlers,
and they should be expected to influence the decision as to the best
pattern to apply.

Richard.
Jul 20 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.