If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I typed it up just now as an example but its a simplification of another working object. So ignore any syntax errors and just look at the concept. It works. Is it a good idea? Will I run into bugs later? Is it w3c kosher? I haven't found any documentation on this online.

BTW, JavaScript doesn't support true private/public classing (at least not yet), what you are doing is using scope/closure to emulate it. There's not wrong with that though.

In this case, you need to follow the scope/closure rules, you can't define onclick using a string'ed code, it would be like attempting to call "privateMethod()" from a global context, so you need to change it to

Code:

element.onclick = privateMethod;

Regarding kosher-ness, JavaScript is governed by ECMA, not W3C. The HTML DOM interface is governed by W3C.

My Bad

Yeah, I intended to write it as:

Code:

element.onclick = privateMethod;

My real concern is over:

Code:

var that = this;

I started in C++ so I tend to think about how objects exist memory. I assume that because the functions and vars are in the scope of the greater object, that they are created with the object. So if you were to create a dozen of these objects, you would have a dozen copies of each function and var. So far this appears to be true in FireFox.

My question is really about how this works in terms of cross browser compatibility, especially when the situation is complicated by a callback. When I assign a callback, will it reference that specific instance of the function? If so, will the function always have access to everything that was defined in it's scope?

Cross-browser should be fine. I had project with dynamically defined functions passed around like candy, and the internal code actually worked flawlessly on IE4. On Gecko side it work on everything from Netscape 6 and up.

The project as a whole only worked on IE 5 due to the lack of W3C DOM support on IE4.

BrickHouse, the main problem with this kind of code organization is performance. New copies of every function are created with every new object instance. That means when there are many instances of real and large classes organized this way (I say "class" loosely, of course), then the code will consume a lot of memory and run slowly.

So while this technically works, it isn't always practical. As it turns out, there's no good way to do this. Eventually we need to accept that JavaScript doesn't support private members, and the best we can do is mark private members with an underscore.

I second Jeff Mott's opinion. For too long we have tried hacking JavaScript to be an OOP language like C++, and all we do is create more work for the browser. JavaScript is what it is: A language with prototype based classes in which all class members are public.