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