Add and object or a function?

[RobG]

I am playing with a script that will allow columns of a table to be
moved by dragging them left or right. To do this with functions is
fairly straight forward, however after looking at Richard Cornford's
version of Table Highlighter[1] I decided to do it using an object.

Richard's basic code structure is:

var SomeObject = (function()
{
function someFn01(){
// statements
// return something
}
function setOnEvent01(arg1, arg2){
return (function() {
// statements
});
}
return (function(arg1, arg2, argN){
// use someFn01() & setOnEvent01()
})
})();
Are there any particular benefits to this style? It encapsulates all
the functions and variables within a single object, but are there any
others?

Will this expose IE's memory leak problem so that I need to use
Richard's finalizeMe() or something similar?

I intend using this with an onload function that passes a class name
that's used to get references to all the tables that can be re-ordered
with drag 'n drop. It will probably attach mousedown/move/up events to
the tables, get and keep references to all the columns and their
positions and other stuff like indicate which column is being dragged,
where it will go when dropped, etc.

My alternative is to have a constructor that creates an object for each
table to hold data relevant to each table (e.g. references to columns)
and add methods to the object prototype for moving the columns.

Is Richard's way clearly better, or is it just a preference for a
particular coding style?
1.
<URL:http://www.litotes.demon.co.uk/example_scripts/tableHighlighter.html>
--
Rob

[Richard Cornford]

RobG wrote:

I am playing with a script that will allow columns of a table
to be moved by dragging them left or right. To do this with
functions is fairly straight forward, however after looking at
Richard Cornford's version of Table Highlighter[1] I decided
to do it using an object.

Richard's basic code structure is:

var SomeObject = (function()
{
function someFn01(){
// statements
// return something
}
function setOnEvent01(arg1, arg2){
return (function() {
// statements
});
}
return (function(arg1, arg2, argN){
// use someFn01() & setOnEvent01()
})
})();
Are there any particular benefits to this style? It
encapsulates all the functions and variables within a single
object, but are there any others?
Encapsulation is almost the entire point of the exercise. It can provide
very slight performance gains in some environments, but not to the
extent that this approach is worth pursuing for that reason.
Will this expose IE's memory leak problem so that I need
to use Richard's finalizeMe() or something similar?
Anything that produces a circular reference chain that includes a COM
object (so IE's DOM nodes and other objects) will produce IE's memory
leak. Closures produce less obvious circular references, if you don't
appreciate what you are doing. But an action as simple as ginning an
Element an ID and then any intrinsic event attribute will theoretically
produce a circular reference (The ID causes a global property to refer
to the Element, the Element refers to the resulting intrinsic event
handling function, and the event handling function refers to the global
object on its scope chain). Given how easy it is to produce memory leaks
on IE I would rather explicitly create those circular references, know
that I am doing it and consequentially handle the explicit breaking of
those references.

However, it should be noted that some closure-based approaches can
actually avoid circular references where they may otherwise be required.
This is particularly true for the creation of event handlers as return
values from functions, as the handlers can refer to their Element as -
this - and access the object through the closure, so the object itself
does not have to hold on to a reference to the Element, it can be passed
that reference when the event handler fires.
I intend using this with an onload function that passes a
class name that's used to get references to all the tables
that can be re-ordered with drag 'n drop. It will probably
attach mousedown/move/up events to the tables, get and keep
references to all the columns and their positions and other
stuff like indicate which column is being dragged, where it
will go when dropped, etc.
That all seems reasonable, and can be implemented in many ways.
My alternative is to have a constructor that creates an
object for each table to hold data relevant to each table
(e.g. references to columns) and add methods to the object
prototype for moving the columns.

Is Richard's way clearly better,
No. 'Better' cannot be reasonably assessed without a context to provide
criteria for the judgement. Your context would suggest an OO approach
but not necessarily any particular style of OO javascript.
or is it just a preference for a
particular coding style?

In context it was an experiment with a particular style of coding. It
worked well enough to produce a well-encapsulated and clearly defined
object. My thinking has moved on a bit since then but it is still a
style that I use when it seems appropriate.

Richard.

[RobG]

Richard Cornford wrote:

RobG wrote: [...]

Are there any particular benefits to this style? It
encapsulates all the functions and variables within a single
object, but are there any others?

Encapsulation is almost the entire point of the exercise. It can provide
very slight performance gains in some environments, but not to the
extent that this approach is worth pursuing for that reason.

That's as I thought - it has ramifications for re-use that affect the
overall architecture of an application.

Will this expose IE's memory leak problem so that I need
to use Richard's finalizeMe() or something similar?

Anything that produces a circular reference chain that includes a COM
object (so IE's DOM nodes and other objects) will produce IE's memory

Hmm ... I don't know enough about such things yet. I thought one of the
good things about using a browser and open standards was to get away
from a lot of the underlying implementation issues, but I guess
expecting it to be fully realised is a bit of a pipe-dream.
[...]

Is Richard's way clearly better,

No. 'Better' cannot be reasonably assessed without a context to provide
criteria for the judgement. Your context would suggest an OO approach
but not necessarily any particular style of OO javascript.

or is it just a preference for a
particular coding style?

In context it was an experiment with a particular style of coding. It
worked well enough to produce a well-encapsulated and clearly defined
object. My thinking has moved on a bit since then but it is still a
style that I use when it seems appropriate.

I had seen the same style from YEP. The bottom line being use what is
most appropriate for the circumstance - the catch being knowing enough
to make the decision (or even what the options are).

Thank you for the reply.
--
Rob

[Richard Cornford]

RobG wrote:

Richard Cornford wrote: <snip>

Anything that produces a circular reference chain that
includes a COM object (so IE's DOM nodes and other objects)
will produce IE's memory

Hmm ... I don't know enough about such things yet. I thought
one of the good things about using a browser and open standards
was to get away from a lot of the underlying implementation
issues, but I guess expecting it to be fully realised is a bit
of a pipe-dream.

We are talking about a browser bug, and a long-standing one. It is
becoming increasingly significant because people are trying to do ever
more on web browsers, and so inevitably on IE. The whole AJAX idea is
predicated on not changing pages in a browser so garbage collection
issues (and particularly bugs) seem the issue of the moment.
[...]

Is Richard's way clearly better,

<snip> I had seen the same style from YEP.
Credit where it is due, Yep was the first person that I observed using
the inline execution of a function expression. Having seen that, and
realising that it was compliantly reasonable and valid in javascript, I
noticed that it could be applied to extending Douglas Crockford's
technique for private instance members to provide private static members
(using a similar emulation). Once Yep had seen the application he picked
it up and ran with it a bit.
The bottom line being use what is most appropriate for
the circumstance - the catch being knowing enough
to make the decision (or even what the options are).

There is a lot of judgement involved, and many opinions. I like
encapsulation because it can eliminate the possibility of accidental
interactions. That is a good thing in a large and complex system and a
total irrelevance in a score of lines of code on a web page.

Richard.