From: Richard Cornford on
On Jun 4, 1:33 pm, Ry Nohryb wrote:
> On Jun 3, 4:32 pm, Richard Cornford wrote:
>> (...)
>> Yes, so that is one application of closures to achieve an
>> emulation of private instance members in javascript. It
>> provides no evidence of his being in a position to provide
>> a 'private static' emulation, and the fact that he did not
>> propose such an emulation when responding to a thread that
>> directly addressed the question suggest that he was not
>> aware of any such application of closures. (...)
>
> OK. It's time for a rewind then, ISTM.
>
> I say: it's my understanding that you're claiming that the
> use of:
>
> var Constructor= (function f () { ... })();
>
> instead of
>
> function f () { ... }; var Constructor= f();
>
> is your invention ("you got the ball rolling").

What has your "instead of" got to do with anything? Have you examples
of that second formulation being used (for anything pertinent) prior
to the 'class variable' thread I mentioned? When did this become a
matter of alternatives?

And that was not what I was claiming. What I am claiming is that using
an immediate call to a function expression to achieve some notion of
'private' and/or encapsulation was may invention (in the absence of
any evidence of anyone publishing the possibility prior to my doing
so).

The - var Constructor = (function(){ ... })(); - above is only an
application of that idea, albeit the first such application published
(and the application that has proved, in the intervening years, the
least interesting/useful of the many possible formulations).

> If that's not it, please, tell me what is it, exactly,
> that you're claiming as your invention,

An immediate call to a function expression to achieve some notion of
'private' and/or encapsulation. That is, the subject of this thread
(even if it is not accurately expressed in the subject).

> with an example ?

(function(){ ... })();

or, if you prefer the parentheses in the other order:-

(function(){ ... }());

The parentheses around the function expression being optional in some
contexts, and possible arguments and the handling of possible return
values being subject to the needs of the context.

Richard.
From: Ry Nohryb on
On Jun 4, 2:59 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk>
wrote:
> (...) Have you examples
> of that second formulation being used (for anything pertinent) prior
> to the 'class variable' thread I mentioned? (...)
> (...) What I am claiming is that using
> an immediate call to a function expression to achieve some notion of
> 'private' and/or encapsulation was may invention (in the absence of
> any evidence of anyone publishing the possibility prior to my doing
> so). (...)

See:

http://groups.google.com/group/comp.lang.javascript/msg/ee98e9f5069376c0

<quote>
It does what you are asking for. The reason it works as a singleton is
because of the line:

> return Sequencer;

Any function constructor that does not explicitly return a value
returns this. However, to override the behavior, you return an
explicit object.

My question is: why go through all of the trouble of using new? Once
you initialize the object:

Sequencer ( );

The private array and inner function exist. Therefore all other
objects in the system can use the reference:

Sequence.next ( )

This allows them to obtain the next sequence. If you change your
function to the following:

( function Sequencer () {
var a = new Array();
Sequencer.next = function (s) {
if (typeof a[s] != "undefined") {
return ++a[s];
}
a[s] = 0;
return a[s];
};
} )( );

All other objects can now reference the inner method without using
new. Put another way, once a function executes it becomes a globally
accessible function *object*, so why bother with new. This is how I do
all of my Singletons.

By the way, if you are trying to build components and you do not like
the idea of binding to a specific object name, you can loosen the
coupling:

function Foo ( seq ) {
... do something ...
this.sequencer = seq;
}

var f = new Foo ( Sequencer );
var x = f.sequencer.next ( );
etc.

One final note. Using the pattern:

( function Sequencer ( ) { ... } )( );

Makes a function automatically execute as the interpreter hits it.
Just a lazy way instead of:

function Sequencer ( ) { ... }
Sequencer ( );

Dale Hurtt
</quote>
--
Jorge.
From: Richard Cornford on
On Jun 6, 3:14 pm, Ry Nohryb wrote:
> On Jun 4, 2:59 pm, Richard Cornford wrote:
>
>> (...) Have you examples
>> of that second formulation being used (for anything pertinent)
>> prior to the 'class variable' thread I mentioned? (...)
>> (...) What I am claiming is that using an immediate call to a
>> function expression to achieve some notion of 'private' and/or
>> encapsulation was may invention (in the absence of any evidence
>> of anyone publishing the possibility prior to my doing so). (...)
>
> See:
>
> http://groups.google.com/group/comp.lang.javascript/msg/ee98e9f5069376c0

Good, you fond one. I have looked but Google's group archives are not
exactly set up for searching by code structure. The idea is certainly
there, but it is a bit unfortunate that the implementation is so very
faulty (to the degree that it will not work in non-JScript
environments, and is relying on JScript's handling named function
expressions twice (once during variable instantiation and once
inline)).

> <quote>
> It does what you are asking for. The reason it works as a singleton
> is because of the line:
>
> > return Sequencer;
>
> Any function constructor that does not explicitly return a value
> returns this. However, to override the behavior, you return an
> explicit object.
>
> My question is: why go through all of the trouble of using new?
> Once you initialize the object:
>
> Sequencer ( );
>
> The private array and inner function exist. Therefore all other
> objects in the system can use the reference:
>
> Sequence.next ( )
>
> This allows them to obtain the next sequence. If you change your
> function to the following:
>
> ( function Sequencer () {
> var a = new Array();
> Sequencer.next = function (s) {
> if (typeof a[s] != "undefined") {
> return ++a[s];
> }
> a[s] = 0;
> return a[s];
> };
>
> } )( );
>
> All other objects can now reference the inner method without using
> new. Put another way, once a function executes it becomes a globally
> accessible function *object*, so why bother with new. This is how
> I do all of my Singletons.
<snip>

In ECMAScript terms, the Identifier - Sequencer - is only visible from
inside the function expression, so this useless as a process because
the Identifier will not resolve outside of the function expression, so
calling - Sequence.next ( ) - would not be practical. Presumably this
was only ever tested/used on IE, if at all.

It is also the case that where this 'works' it becomes possible to
call - Sequencer - (or at least one of the two 'Sequencer' function
multiple times, which make you wonder where the '"Singelton" bit come
into it.

> Dale Hurtt
> </quote>

Richard.
From: Ry Nohryb on
On Jun 8, 12:40 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk>
wrote:
> On Jun 6, 3:14 pm, Ry Nohryb wrote:
>
> > See:
>
> >http://groups.google.com/group/comp.lang.javascript/msg/ee98e9f5069376c0
>
> Good, you fond one. I have looked but Google's group archives are not
> exactly set up for searching by code structure. The idea is certainly
> there, but it is a bit unfortunate that the implementation is so very
> faulty (to the degree that it will not work in non-JScript
> environments, and is relying on JScript's handling named function
> expressions twice (once during variable instantiation and once
> inline)).
>
> <snip>
>
> In ECMAScript terms, the Identifier - Sequencer - is only visible from
> inside the function expression, so this useless as a process because
> the Identifier will not resolve outside of the function expression, so
> calling - Sequence.next ( ) - would not be practical. Presumably this
> was only ever tested/used on IE, if at all.
>
> It is also the case that where this 'works' it becomes possible to
> call - Sequencer - (or at least one of the two 'Sequencer' function
> multiple times, which make you wonder where the '"Singelton" bit come
> into it.

Yes, yes, and yes. IOW ( 3*yes ).

P.S. Where I come from there's the saying that where there's one,
there's two...
--
Jorge.