Julian Kennedy

Julian,

> I am a big fan of your site. Possibly the best of its kind on The Web.

Thankyou :)

> The common method, *getTheArea, would be better assigned to the
> constructor's prototype

Since I am creating the constructor, this is not really necessary. When I
create the constructor, I am also creating the prototype itself. So adding
them at this stage is the same as adding them using the prototype later.

Indeed, it would be possible to add it to the prototype, but the real
purpose of the prototype is to add the property to all instances of that
object, even if they are already existing objects. So for example I could
create several strings, then later decide to add a new method to them, so I
add it to the String.prototype, and they should all inherit that property.

> I realise, that you may have conciously made this decision, however, so as
> not to confuse the issue further by bringing inheritance into the equation.

And this is quite true :)
I am trying to give a general introduction, and while I know that you could
go absolutely mad:
http://www.kevlindev.com/tutorials/javascript/inheritance/
and use the prototype to try to make JavaScript behave more like C++ or
Java (perfectly legitimate use of it), this is unnecessary for most
JavaScript programming, and not something I would want to teach people in
an introductory JavaScript tutorial.

The only reason that page uses that construct to add methods is for
demonstration purposes later on. It is not necessary, and it makes code a
lot more easy to read (in my opinion) to put things inside the main
constructor as I have done. Otherwise you would have to jump from function
to function just to work out what properties or methods your object may
have.

I think maybe I will add something in about inheriting from a parent class
later, but I will still try to keep things simple.

> The problem is that Firefox is reporting *true for *[event].ctrlKey whether
> or not CTRL is depressed when the event is a SELECT *onchange event.

Hmm - has this been reported to bugzilla?
http://bugzilla.mozilla.org/


Mark 'Tarquin' Wilton-Jones - author of http://www.howtocreate.co.uk/

Julian,

I have made some updates, including an advanced section showing how to use
prototype, public and private properties and class inheritance:
http://www.howtocreate.co.uk/tutorials/javascript/objects#advobj

> mycircle.prototype.retArea = getTheArea;
> mycircle.prototype.retCirc = function ()  { ...  };
> ..since the assignments then do not have to be made individually to each
> and every new object.

Well, there are advantages and disadvantages. It may be a little faster
since you do not need to recreate the methods each time. However, even so,
when you create a new instance of that object, internally, a new copy of
the method will still be created and attached to the object, so the time
savings would be minimal.

Aditionally, you deny yourself the possibility of creating private
properties, as a privileged method can only be declared within the bounds
of the constructor function.

(Personally, I do not like the way I defined the retArea method - as a
referenced function - but that was just to demonstrate that "if you see
someone's code with this in it, this is what they are doing")

As a more important point, using prototype for everything can be much less
readable, as it breaks your constructor object up into several pieces, so
trying to work out which methods and properties apply to what objects gets
much harder. Additionally, many scripters are not aware that you can use
the prototype, so passing your code onto someone else might cause them
problems maintaining it.

> It's probably a good idea to present methods in this way, but I'd encourage
> you to follow on to show how these common members can then be attached to
> the prototype instead.

Done :)

Thanks for the criticisms, hope something useful has come out of it.

Tarquin

> alert(testcircle.texture); //alerts 'red'   <-- !!

doh! fixed :)

> In my view, 'private members' [...] are very much an emulation

Absolutely. They are a by-product of closures, and personally I see little
use for them.

> Really, anyone reading who doesn't know the object model inside out
> should leave all this well alone !

Yep. basically I just want to let the Java programmers (who complain at me
that JavaScript can't do class inheritance) know that it is better than
they think.

> > it copies the properties and values of the mycircle
> No. It remains a mycircle. It just happens to be part of a prototype chain
> now too.

It appears I had misunderstood something about prototype chaining. After
creating a mysphere, I then add a property to the prototype of the mycircle,
and amazingly, the mysphere also got that property. JavaScript is smarter
than I realized. I was under the (mistaken) impression that it had
completely lost the reference to the mycircle prototype. Apparently not.

I will update that description, once I can put my thoughts into human words
;)

> Run [script1.js] in the attached zip.

interesting, I didn't realise you could also delete properties and get back
the inherited ones, but that refers to my statement above :)

>  window.anObject = this;

var allObs = [];
function myobject() {
    allObs[allObs.length] = this;
    ...etc...
}

I have seen stuff like this many times, where 'allObs' is then used to
refer to all objects of that class. However, if we did some inheritance
here, nasty things will happen, because allObs[index] will now refer to the
prototype of the inheriting class, and not the individual object.

> if(!arguments.length) return this;

why return 'this'? if we are creating a 'new whatever()' we have no need to
return anything. return; on its own should work.

> this.p0 = p0

Took a little while to get my head around this ...
Seems simple, but I was trying to work out exactly what 'this' referred to.
Normally, in a function, it refers to the window object.
You were refering to it as a method of the prototype, which should mean
that the properties are created as properties of the prototype, and not the
object itself. Of course, I had not realised that since we have now created
an instance of the mysphere, the method is now a method of the instance and
not the prototype. Bah! my poor head.

> there's a little less juggling

indeed, a plus point. thanks for the education :)

> (not present in IE5)

argh :( never tried in IE 5. I see it is an ECMAScript 3 method. Makes
sense.

> Any good ?

Very. :)

Jude,

Ok, I retract part of my last email.

here is the problem with your technique. You cannot re-use the .inherit
method name. each time it replaces the previous ones, so if you try
something like this:

function Sphere2(x,y,z,r){
    if(!arguments.length )return this;
    this.inherit(x,y,z,r);
    this.foo = 'bar';
}
Sphere2_ = Sphere2.prototype = new Sphere;
Sphere2_.inherit = Sphere;
var testsphere2 = new Sphere2(3,4,5,6);

You will get a recursive call to '.inherit', resulting in a script error
(or an endless loop). so each subclass would need to use a different name
for that method.

Since scripts that use classes this heavily may well have several levels of
inheritance, you would have to remember each .inherit method name.

The prototype.getready avoids this, because it attaches to the prototype
(and is accessed through the prototype, not directly). Unfortunately, since
it is not supported by IE 5 I will have to work out an alternative.

Maybe the only option is to use a simple system to remember the method name,
like maybe .inheritClassname, eg .inheritCircle or .inheritSphere

Am I correct in this analysis? Or do you already know of an alternative?

Cheers

Tarquin

Jude,

apologies for the multiple emails ... :)

I have decided that the getready way is better, simply because it allows
the same name to be used each time without any conflicts, and without
needing to know how many parent classes there are above the current class.
It may be a longer way round than yours, but in the long run, I believe it
is for the better.

As for IE 5, that bit is simple. Instead of referencing the method then
using 'call', I use
this.tempReady = parent_class_name.prototype.getready;
this.tempReady(a,b,d);
tempReady will be overwritten at each stage as it passes back up the chain,
each time referencing the correct method, and will then run as a method of
the current object, ensuring that all new properties are attached to the
correct object.

Works like a charm. It's even working in Ye Olde IE 4 and NS 4 now, as well
as all of the current browsers. So I am happy with it in its current state.
I have also added in the other amendments (prototype chain, etc.)

Thanks for your input on this, it's been very useful.


Tarquin