Simpleton singleton that installs its own function type properties

[Richard A. DeVenezia]

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.calle e


if (callee.singlet on != undefined)
return callee.singleto n

if (this == window)
return new callee(argument s)

installClassFun ctions()

callee.singleto n = this
return

function installClassFun ctions() {
callee.classMet hod1 = function () {alert('1')} // global function but
property of foo
callee.classMet hod2 = function () {alert('2')}
}
}

foo()
foo.classMethod 1() // 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

[Richard Cornford]

Re: Simpleton singleton that installs its own function type properties

"Richard A. DeVenezia" <radevenz@ix.ne tcom.com> wrote in message
news:bji5ak$j7e 9p$1@ID-168040.news.uni-berlin.de...[color=blue]
>foo() generates elements with event handlers that invoke
>foo function properties.[/color]

Not in this code it doesn't.
[color=blue]
> Is this an abhorrent or misthought pattern ?[/color]

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 ;-)
[color=blue]
> It allows just the one occurence of identifier /foo/ to be changed
> to /whatever/ when need arises and everything should still work.[/color]

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.
[color=blue]
> function foo () {
> var callee = arguments.calle e
>
> if (callee.singlet on != undefined)
> return callee.singleto n
>
> if (this == window)
> return new callee(argument s)
>
> installClassFun ctions()
>
> callee.singleto n = this
> return
>
> function installClassFun ctions() {
> callee.classMet hod1 = function () {alert('1')} // global function[/color]
but[color=blue]
>property of foo[/color]

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.
[color=blue]
> callee.classMet hod2 = function () {alert('2')}
> }
> }
>
>foo()
>foo.classMetho d1() // not normally invoked directly, verifies operation[/color]

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..
[color=blue]
>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.[/color]

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.
[color=blue]
>(Also, no sense in prototyping singleton methods)[/color]

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.