Re: JavaScript Question relating to netWindows

Alex Russell <[email protected]> Fri, 16 Jan 2004 13:26:38 -0800
Newsgroups gmane.comp.windows.devel.netwindows
Organization netWindows.org
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Roy,

All great questions. I hope you don't mind if I cc your questions (and 
my reply) to our mailing list. It's where these kinds of topics can 
benefit many more people than just you and I, and we can get feedback 
from other project contributors. To sign up for the list yourself, 
you can visit:

http://netwindows.org/mailman/listinfo/devel_netwindows.org

On Friday 16 January 2004 11:58 am, you wrote:
> Hi Alex,
>
> I hope you had a good Christmas and New Year. I've been busy doing
> other things at work and trying to get my head around JavaScript OO
> paradigm.

Great! It's always neat to see someone diving into the world of 
closures and prototype-based inheritance.

> I get the workings of using 'this.' and creating variables etc.
> against the object that can be accessed at a later time. This
> corresponds to access-level public in other languages.

Correct.

> If I 'add' the object created to an array, I can manipulate the
> variable value of that instance on the object from an event
> generated elsewhere in the browser.

Yep. In fact, you can add properties and methods to the object at a 
later time i you like, since everything is mutable in JavaScript at 
any time.

> What I don't understand, is 'could' you do the same as above, but
> create the variable with the equivalent access-level of private
> (i.e. using 'var'), add accessor functions (each function being
> added to the 'this.' namespace), and manipulate this private value
> from an event generated in the browser?

Yes. JavaScript has a provision for the concept of "closures", which 
are essentially functions with namespaces that exist as long as they 
are needed. This is one of legs that "classes" in JS are implemented 
on. I'll spare you the bloody details, but it is worth noting that 
the situation you describe will only work so long as the methods you 
refer to are instance-level members of the object. So for instance, 
you have a class "foo", here's two examples of how you might write 
foo, the first will NOT work as you expect, whereas the second one 
will:
// --------- the first way ----------
// class def
function foo(){
	var privateVar = "bar";
}

// class level, or "shared" methods:
foo.prototype.setPrivateVar = function(val){ 
	privateVar = val;
}
foo.prototype.getPrivateVar = function(val){ 
	return privateVar;
}

var baz = new foo();
alert(baz.getPrivateVar()); // will throw an exception!

// --------- the right way ----------

// class def
function foo2(){
	var privateVar = "bar";

	// instance level methods, members of the instantiated 
	// object and not the class prototype:
	this.setPrivateVar = function(val){ 
		privateVar = val;
	}

	this.getPrivateVar = function(val){ 
		return privateVar;
	}
}

var baz2 = new foo2();
alert(baz2.getPrivateVar()); // will alert "bar"

> An example would be say an object that holds table information. One
> of the properties maybe the number of rows in the table. I would to
> get the value of the number of rows from the object via a getter
> accessor function when the user clicks on the 'Add Blank Row'
> button, but I don't want anything to be able to update the objects
> row property except via a setter accessor function.

You write Java for a living, don't you? = )

JavaScript doesn't provide many protections other than the 
namespace-level access restrictions outlined above (which are 
something of a side-effect anyway). If someone wants to re-define 
your class or add their own accessor methods to your objects, or 
whatever, they can do so at runtime with impunity. Everything in 
JavaScript is mutable, all the time.

> I hope that makes sense. If it can't be done, just say no.

There's a great overview of OOP in JS at:

http://fm.dept-z.com/index.asp?get=/Resources/OOP_with_ECMAScript/

> Finally, netWindows is basically hard coded to render HTML. Do you
> have any plans to enable it to determine if the browser supports
> SVG (either directly or via a plug-in) or XUL, and then where
> netWindows can render using theses markups?

Yes, both of these prospects are exciting to me and I plan to do an 
SVG port as soon as practicable. Right now, the state of HTML/SVG 
integration in browsers leaves waaaaay too much to be desired for my 
tastes. I've considered porting widgets to work with the Adobe 
plugin, but it just seems like such a waste of time until they can 
"play" better with enclosing HTML documents.

> If not, would you be interested in taking it this way?

Right now, we use "factory functions" to create widget objects and tie 
them to DOM representations. Porting to a new DOM-compliant markup 
syntax will, in most cases, only require replacing the factory 
functions (although I suspect that there's a lot more objects 
directly manipulating the HTML DOM than I'd like to admit). It is 
something that I've thought about, and something I'd like to see 
happen. We just need a user base for it.

- -- 
Alex Russell
[email protected]   BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
[email protected] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD8DBQFACFcOoV0dQ6uSmkYRAmjBAJ4rUD40+3LdsNYauT6BqOhp+fvEmACeL1Wc
En2wbMnyUSsa/IyTMM6ZaU4=
=DhRv
-----END PGP SIGNATURE-----


_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org