[purisme] prototypes / OO in JavaScript *

[drm]

Ik zie regelmatig hier op GoT oplossingen voorbijkomen waarbij de prototype van bijvoorbeeld Array, HTMLElement of dergelijke "klassen" _{laat ik het zo maar even noemen} gemanipuleerd wordt. Een goed voorbeeld hiervan zag ik zojuist weer gepost worden: [rml]crisp in "[ JS] de hoogste waarde van 4 meetellen"[/rml]

Nou ben ik eigenlijk een beetje in dubio of dat wel zo netjes is...

Aan de ene kant denk ik: het werkt mooi/handig, het is transparant, waarom niet?

Aan de andere kant denk ik: We roepen hier altijd heel veel over standaarden, toepassing van zaken zoals ze voorgeschreven zijn. Functionaliteit toevoegen buiten de standaarden om: moeten we dat eigenlijk wel doen?

Wat vinden jullie?

_{Overigens heb ik het dan niet over zaken die niet geimplementeerd zijn door bepaalde niet nader te noemen browsers}

[crisp]

Het grootste risico dat natuurlijk bestaat is wanneer je methods gaat toekennen die in javascript niet bestaan (JS is niet erg rijk bedeeld als het gaat om gestandaardiseerde methoden ivm bijvoorbeeld PHP en JAVA), maar die wel qua naamgeving overeenkomen met gestandaardiseerde methoden zoals in voornoemde talen.
Mensen die je code lezen zullen dan niet snel doorhebben dat het geen standaard methoden zijn, en er op stuk lopen op het moment dat ze je code willen gaan hergebruiken, maar de prototypes over het hoofd zien

Dat is echter ook het enige argument tegen dat ik op dit moment kan bedenken, want waarom zou het niet netjes zijn?
Ok, een functie-call is vaak net even sneller, maar dat is maar marginaal; ik denk dat het gebruik van custom methods zelfs juist netter is omdat je dan meer consequent aan het programeren bent.

[Annie]

drm schreef op 09 maart 2004 @ 22:06:
Aan de andere kant denk ik: We roepen hier altijd heel veel over standaarden, toepassing van zaken zoals ze voorgeschreven zijn. Functionaliteit toevoegen buiten de standaarden om: moeten we dat eigenlijk wel doen?

Waarom zouden standaarden dit niet toestaan? Ik zie het probleem niet zo. Of je een functionaliteit nu toevoegt aan het Array object of je maakt er een losse functie van maakt dan voor mij niet meer zoveel uit.

Het wordt misschien gevaarlijk wanneer je bestaande methods gaat overschrijven lijkt me.
_{(er van uitgaande dat iedereen zo lui is wat betreft documentatie als ik)}

dit?

code:

var a = [1, 2, 3];
var b = a.max();

of dit?

code:

var a = [1, 2, 3];
var b = max(a);

to-mee-to, to-maa-to

[drm]

crisp:
Dat is echter ook het enige argument tegen dat ik op dit moment kan bedenken, want waarom zou het niet netjes zijn? Ok, een functie-call is vaak net even sneller, maar dat is maar marginaal;

Performance is in dit soort discussies nooit een issue, wat mij betreft Da's een implementatieprobleem.

ik denk dat het gebruik van custom methods zelfs juist netter is omdat je dan meer consequent aan het programeren bent.

De nette manier zou imo zijn om een afgeleide eigen implementatie van bijvoorbeeld een array te maken waarin je de standaard functionaliteit van de Array inherit en je je eigen functionaliteit toevoegt. De OO benadering, zeg maar.

Het probleem wat je dan tegen het lijf loopt is dat je jezelf heel erg beperkt als het om codesuiker gaat, zoals het instantieren van een array mbv. de [ .... ] notatie, e.d.

Wat ik er, gevoelsmatig, op tegen heb is dat je eigenlijk tornt aan de "standaard". Het voelt aan als in bijvoorbeeld Java of C++ in de standard library gaan sleutelen omdat je vindt dat een bepaalde methode of class niet precies doet wat je wilt.

[djluc]

Wat ik er, gevoelsmatig, op tegen heb is dat je eigenlijk tornt aan de "standaard". Het voelt aan als in bijvoorbeeld Java of C++ in de standard library gaan sleutelen omdat je vindt dat een bepaalde methode of class niet precies doet wat je wilt.

Je voegt een niet bestaande functionaliteit toe, en plaatst deze op een logische plaats. Omdat deze speciaal voor array's bedoeld is. Niets mis mee volgens mij.

[crisp]

drm schreef op 09 maart 2004 @ 22:31:
[...]
Performance is in dit soort discussies nooit een issue, wat mij betreft Da's een implementatieprobleem.

Met lemmings is dat wel een issue

[...]
De nette manier zou imo zijn om een afgeleide eigen implementatie van bijvoorbeeld een array te maken waarin je de standaard functionaliteit van de Array inherit en je je eigen functionaliteit toevoegt. De OO benadering, zeg maar.

Het probleem wat je dan tegen het lijf loopt is dat je jezelf heel erg beperkt als het om codesuiker gaat, zoals het instantieren van een array mbv. de [ .... ] notatie, e.d.

tsja, JS is nu eenmaal niet OO-based maar prototype-based, live with it

Wat ik er, gevoelsmatig, op tegen heb is dat je eigenlijk tornt aan de "standaard". Het voelt aan als in bijvoorbeeld Java of C++ in de standard library gaan sleutelen omdat je vindt dat een bepaalde methode of class niet precies doet wat je wilt.

Het is niet dat een bepaalde method niet precies doet wat je wilt, maar meer dat een bepaalde method er gewoon simpelweg standaard niet is in JS; ik ken maar weinig methods in JS die niet doen wat ik wil

[oh,when?]

drm schreef op 09 maart 2004 @ 22:31:
De nette manier zou imo zijn om een afgeleide eigen implementatie van bijvoorbeeld een array te maken waarin je de standaard functionaliteit van de Array inherit en je je eigen functionaliteit toevoegt. De OO benadering, zeg maar

Nope. Dat is misschien het geval in traditionele 'class-based' talen zoals C++ of Java, maar het geval is dat Javascript veel meer weg heeft van de 'andere kant', talen zoals Smalltalk en Eifel Methodes toevoegen via het prototype object, is juist daarvoor bedoeld, zoals de specificaties melden:

In a class-based object-oriented language, in general, state is carried by instances, methods are carried by classes, and inheritance is only of structure and behaviour. In ECMAScript, the state and methods are carried by objects, and structure, behaviour, and state are all inherited.

[..]

A prototype is an object used to implement structure, state, and behaviour inheritance in ECMAScript. When a constructor creates an object, that object implicitly references the constructor’s associated prototype for the purpose of resolving property references. The constructor’s associated prototype can be referenced by the program expression constructor.prototype, and properties added to an object’s prototype are shared, through inheritance, by all objects sharing the prototype.

ECMAscript en daaruit afgeleide talen zoals Javascript en Actionscript 1.0 zijn heerlijke dynamische talen om in te ontwikkelen, soms zelfs mooier in oplossing dan een 'traditionele taal'. Voor een diepgaande vergelijking tussen prototype-gebaseerde talen en class-gebaseerde talen, bekijk eens de volgende link van MIT AI Lab:

Using Prototypical Objects to Implement Shared Behavior in Object Oriented Systems


* oh,when? heeft overigens een aversie tegen de term 'prototyping'...wtf is dat...is een nietszeggende term, en daarnaast niet eens goed. Je zegt toch ook niet 'ik ga eens OO-en in Java? Ik geloof dat Pelle en willem169 hier ooit eens mee zijn begonnen...ga u schamen!

[ Voor 3% gewijzigd door oh,when? op 09-03-2004 22:56 ]

[drm]

oh,when?:
ECMAscript en daaruit afgeleide talen zoals Javascript en Actionscript 1.0 zijn heerlijke dynamische talen om in te ontwikkelen, soms zelfs mooier in oplossing dan een 'traditionele taal'. Voor een diepgaande vergelijking tussen prototype-gebaseerde talen en class-gebaseerde talen, bekijk eens de volgende link van MIT AI Lab:

Using Prototypical Objects to Implement Shared Behavior in Object Oriented Systems

Hm interesting Ga ik zeer binnenkort even doorlezen.

* oh,when? heeft overigens een aversie tegen de term 'prototyping'...wtf is dat...is een nietszeggende term, en daarnaast niet eens goed. Je zegt toch ook niet 'ik ga eens OO-en in Java? Ik geloof dat Pelle en willem169 hier ooit eens mee zijn begonnen...ga u schamen!

Ik heb de topictitel even aangepast voor je

[Clay]

Annie schreef op 09 maart 2004 @ 22:29:

[...]

dit?

code:

var a = [1, 2, 3];
var b = a.max();

of dit?

code:

var a = [1, 2, 3];
var b = max(a);

to-mee-to, to-maa-to

Duidelijk dat eerste Als je alles op die 2e manier doet krijg je een grote soep van losse functies waar de structuur helemaal zoek is. Doe mij dan maar OO style, waar ik alleen dat bij een object aan kan roepen wat er ook echt bij hoort.

kwam net toevallig nog deze link tegen:
http://www.sitepoint.com/print/1194

Al druist het mij dan weer tegen het gevoel in om te gaan inheriten van instances

ECMAscript en daaruit afgeleide talen zoals Javascript en Actionscript 1.0 zijn heerlijke dynamische talen om in te ontwikkelen, soms zelfs mooier in oplossing dan een 'traditionele taal'.

Daar sluit ik me helemaal bij aan

[Verwijderd]

Sommige zaken zijn gewoon erg handig. In IE5 zijn bijvoorbeeld methods als push en pop op het Array object niet beschikbaar. Het is een kleine moeite om hier een implementatie op te maken.

Waar ik toch altijd veel gebruik van heb gemaakt is bijv:

code:

Array.prototype.find = function(needle) {
    for(var i in this){
      if (this[i] == needle){
         return i;
        }
    }
    return false;
}
Array.prototype.push = function(el) {
    this[this.length] = el;
}
Array.prototype.remove = function(index) {
    for (i=index;index<this.length-1;index++){
        this[index] = this[(parseInt(index)+1)];
    }
    this.length=this.length-1;
}

Ik gebruik vooral de find en remove methods graag. De push is simpelweg meer een additionele fix voor IE5.

[Verwijderd]

Misschien is dit wel een beetje gerelateerd:
http://w3future.com/weblo...ContextInProgrammingpart2

Ik denk ook dat je met prototyping de boel wat duidelijker kan maken qua code, het scheelt weer een extra argument in je functie, dus ik zie eigenlijk geen nadelen.

[André]

Ik zie het meer zo: er is een chassis met een carroserie, dat lijkt nergens op. Maar je kunt dat uitbreiden tot een heuse auto, eventueel tot een Ferrari. Puur door eigen functionaliteit er aan te hangen.

Ik vind bijvoorbeeld de indexOf functie voor het array object ontzettend makkelijk. Naar mijn inzien mist die functie dus plak ik hem er zelf even aan (al genoemd door gordijnrail zie ik ).

[Verwijderd]

André schreef op 09 maart 2004 @ 23:37:
Ik vind bijvoorbeeld de indexOf functie voor het array object ontzettend makkelijk. Naar mijn inzien mist die functie dus plak ik hem er zelf even aan (al genoemd door gordijnrail zie ik ).

Precies. JS is wat dat betreft een heerlijke quick&dirty taal. Het mist daardoor de structuur om echt lekker diep te gaan, maar als dit soort dingen werken smelt mijn hart :

JavaScript:

var _bAlert = true;

// Laten we alert eens overschrijven!
alert = function() {
    if(_bAlert) {
        var sAlert = '';
        for(var i=0; i<arguments.length; i++) {
            sAlert += typeof arguments[i] + '\t';
            sAlert += arguments[i] + '\n';
        }
        _bAlert = confirm(sAlert);
    }
}

alert(1,'jaja',true); 

Hiermee kun je van die oneindige alert-loopjes voorkomen, want zodra je een keer op cancel hebt gedrukt komen ze niet meer tevoorschijn. Hardstikke handig tijdens ontwikkelen.

[Clay]

die is goed.

zelfde kan je ook doen met window.open (en eigenlijk alles);

JavaScript:

_winOpen = window.open;
window.open = function(url,name,settings) {
   // confirms en tellers oid
   _winOpen(url, name, settings);
}

Het mist daardoor de structuur om echt lekker diep te gaan

Dat weet ik nog zo net niet. Je kan b.v. eigen methodes bakken om objecten van objecten te laten inheriten, en interfaces implementen is ook goed te doen, b.v met dit.

JavaScript:

Function.prototype.extendsFrom = function(Super) {
   var Self = this; 
   var Func = function() {
      Super.apply(this, arguments);
      Self.apply(this, arguments);
   }
   Func.prototype = new Super();
   return Func;
}

kan je dan dit doen:

JavaScript:

function User(name) {
    this.name = name;
}
   User.prototype = {
      login:function() {
         alert('login: ' + this.name)
      },

      logout:function() {
         alert(':w');
      }
   }

  
function Admin(name, level) {
    this.level = level;
}
   Admin = Admin.extendsFrom(User);

en * plop * bij het maken van een instantie van Admin heeft die alle functies van de prototype van User, en User wordt als super aangeroepen om parameters te verwerken.

"interfaces impelementen" kan net zo makkelijk, bv:

JavaScript:

Function.prototype.implement = function(Face) {
   for(var i in Face) {
      this.prototype[i] = Face[i];
   }
}

var SysteemBeheerder = {
   taunt:function() {
      alert('users zijn prutsers!');
   }
}

met:

JavaScript:

function Admin(name, level) {
    this.level = level;
}
   Admin = Admin.extendsFrom(User);
   Admin.implement(SysteemBeheerder);
 
var piet = new Admin('piet', 5);
piet.login();
piet.taunt();
piet.logout();

Dat gaat al best diep

[Clay]

Het was niet mijn bedoeling dit topic dood te slaan met een bak code eigenlijk Het was toch wel iets meer als opening bedoeld...

Blijkbaar kan je trouwens ook dingen aan het window prototypen. window zelf heeft geen prototype, maar de .constructor wel (iig in mozilla en opera. IE niet natuurlijk)

code:

Window = window.constructor;
// alert(Window.prototype == window) // false!

Window.prototype.melp = function() {
   alert('woei');
}

window.melp();

[Annie]

Clay schreef op 10 maart 2004 @ 22:04:

code:

Window = window.constructor;
// alert(Window.prototype == window) // false!

Window.prototype.melp = function() {
   alert('woei');
}

window.melp();

* Annie terug

Wat is dan het verschil met

code:

function melp() { alert('nog meer woei'); }

window.melp();

[ Voor 6% gewijzigd door Annie op 10-03-2004 22:16 ]

[Clay]

naja niets dus alleen de manier waarop je het toewijst, maar daar gaat het topic ook over Als je b.v. een functie specifiek aan window wil hangen, doe je dan gewoon een function, een window.dinges = function, of (als het kan) prototypen, ook is dat de meest omslachtige methode?

[oh,when?]

* oh,when? vraagt zich eigenlijk af of er al browsers zijn met een ECMA 4 implementatie ( class-based ipv prototype-based )?

[Pelle]

oh,when? schreef op 09 maart 2004 @ 22:55:
Ik geloof dat Pelle en willem169 hier ooit eens mee zijn begonnen...ga u schamen!

* Pelle weet van niks
Hier op GoT heb ik voor het eerst kennis gemaakt met dit concept, dus als ik ooit ergens die term genoemd heb dan is dat omdat iemand anders me het verkeerde voorbeeld heeft gegeven