[JS] Gebruik van "prototype" voor object methods

[Verwijderd]

Ik ben benieuwd wat jullie gedachten zijn over het gebuik van prototype voor (o.a.) het definieren van de methodes van een object.

Dus i.p.v.:

code:

function bla_Object(ID) {
    this.ID = ID;
    this.Method = bla_Method;
}

function bla_Method() {
    alert(this.ID);
}

code:

function bla_Object(ID) {
    this.ID = ID;
}
bla_Object.prototype.Method = bla_Method();

function bla_Method() {
    alert(this.ID);
}

Volgens mijn JS boek bespaart het gebruik van prototype geheugen omdat het maar 1 keer hoeft toegekend te worden i.p.v. aan elke instantie van het object.

Wat zijn jullie gedachten hierover? Heeft iemand weleens drastische performance verschillen tussen de twee methodes vastgesteld?

[Bosmonster]

Scheelt sowieso geheugen, das een feit. Op langzamere systemen/browsers, en dan met bedoel ik met name IE4 en IE/Mac is er wel een duidelijk verschil te merken. Zeker als je kijkt dat IE/Mac een enorme bug heeft wat betreft het onthouden van objecten.

Verschil zul je aleen merken als je een systeem hebt waar je automatisch lagen genereert, bijvoorbeeld een menu uit een database. Zelf had ik eens zo'n menu met enkele honderden lagen. Er was een duidelijke snelheidswinst te merken bij creatie op IE4 en IE/Mac.

Verder zou ik wel voor verkorte schrijfwijze gaan (zelf doe ik dit):

function myObject(){

} myProto=myObject.prototype;

myProto.myFunction1=function(myVar){

}

myProto.myFunction2=function(myVar){

}

Verder is er nog een voordeel overigens.. Functies worden niet gecontroleerd als je ze via prototype declareert. Zo kun je in een functie het body-object aanspreken terwijl dat nog niet bestaat. Doe je dit niet via prototyping, dan krijg je hier direct al foutmeldingen over.

[Clay]

Ik maak maar weinig gebruik van prototyping simpelweg omdat ik het er lelijk uit vind zien.

code:

function dinges() {
   this.moveUp    = moveUp;
   this.moveDown  = moveDown;
   this.moveLeft  = moveLeft;
   this.moveRight = moveRight;

   function moveUp() {
   }
   
   function moveDown() {
   }
   
   ...
}

vind ik er een stuk overzichtelijker en netter uitzien dan prototype.blah, en voordeel hiervan is dat je object fucties genest zijn, en dat het dus onmogelijk is ze zonder object aan te roepen. dat kan met prototyping niet.

Maar misschien is het idd sneller, en ik ga het wel degelijk proberen. Ik heb een dhtml "stress test" gemaakt, bestaande uit een pacman veld met 5 monsters met 40+ bij ~30 velden (layers) en een pacman, volledig functioneel, object based zonder prototpying, en het kost Netscape een paar minuten het veld te genereren (real time, je ziet de vakken verschijnen, steeds langzamer naarmate het vordert ) dat zijn dus 1200+ layers IE trekt het niet eens, en ns4 wel!
In mozilla is een veld van 15 bij 15 met 2 monsters al niet te spelen, te traag. Misschien dat dat het is.

[Verwijderd]

Ja, hijs inderdaad heel handig

[Verwijderd]

Op donderdag 06 september 2001 20:00 schreef Clay het volgende:
Ik maak maar weinig gebruik van prototyping simpelweg omdat ik het er lelijk uit vind zien.
[...] voordeel hiervan is dat je object fucties genest zijn, en dat het dus onmogelijk is ze zonder object aan te roepen. dat kan met prototyping niet.

Ja, da's waar...maar dat zie ik niet echt als een probleem. Consequente naamgeving lost een hoop op...

Maar misschien is het idd sneller, en ik ga het wel degelijk proberen. Ik heb een dhtml "stress test" gemaakt, bestaande uit een pacman veld met 5 monsters met 40+ bij ~30 velden (layers) en een pacman, volledig functioneel, object based zonder prototpying, en het kost Netscape een paar minuten het veld te genereren (real time, je ziet de vakken verschijnen, steeds langzamer naarmate het vordert ) dat zijn dus 1200+ layers IE trekt het niet eens, en ns4 wel!
In mozilla is een veld van 15 bij 15 met 2 monsters al niet te spelen, te traag. Misschien dat dat het is.

Ik heb zo'n vermoeden dat het op dit nivo wel voordeel oplevert. Het ziet er absoluut minder overzichtelijk uit, maar als je een object hebt met (bijvoorbeeld) 4 properties en 12 methods dan zou het ongeveer 75% minder geheugen (per toegekend object) kosten om met prototypes methodes toe te kennen. Voor 1200 objects moet dat haast wel performance opleveren.

[Clay]

Het werkt behoorlijk goed zelfs!! De tijd om het speelveld te genereren is teruggelopen van enkele minuten tot een stuk of 10 a 20 seconden en in IE gaat het ook goed nu. dus het scheelt inderdaad behoorlijk wat.
Weer wat geleerd dus

[Verwijderd]

Cool. Staat die stress-test al ergens online? Ik ben benieuwd wat de performance hier is...Draait ie ook op NS6/Mozilla?

[Clay]

Staat niet online nee En in Ns6/Moz werkt het wel, maar niet met 1250 layers, dat wordt totaal niet getrokken, en daar ga ik niet op wachten Een veld van 15 bij 15 duurt daarmee al vrij lang.
Op zich kan Moz wel vrij snel 2000 losse layers genereren, maar in die stress-test wordt er ook nog gamecode uitgevoerd.

Voor een echt speelbare pacman ga ik dan ook geen layers per speelveld gebruiken, maar een gewoon een grote table met x * y plaatjes.
Wat wel vreemd is is dat een layer op hidden zetten ook ongeveer een seconde duurt in IE met zo'n hoeveelheid layers. Het draait gewoon het beste in Ns4

[Verwijderd]

Op donderdag 20 september 2001 13:01 schreef Clay het volgende:
Wat wel vreemd is is dat een layer op hidden zetten ook ongeveer een seconde duurt in IE met zo'n hoeveelheid layers.

Wat? Weeeeeird. Is het DOM of document.all based?

Het draait gewoon het beste in Ns4

Gebruik je new Layer() of iets anders?

Heb je weleens de DOM-based snake game gezien?

[Clay]

het draait op een library die dat gebruikt wat de browser ondersteunt dus voor ie4 document.all, voor ie5 een deel dom, voor ns6 dom, en voor ns4 new Layer().

[Clay]

Heb um nu met meer dan 3200 layers een voorlopig kunnen zowel ie5+ als ns4.x dat prima aan. ik vraag me hard af waar de grens is