javascript en overerving properties

[BoringDay]

Beste mensen,
Momenteel ben ik beetje uitpluizen of het volgende mogelijk is in javascript (protected/public en prototyping even buiten discussie gelaten). Ik wil namelijk een hiërarchie van objecten welke controls (bijv. een menu, dropdownlist .. ect) moeten voorstellen.

<interface>
declaratie object
declaratie properties, propeties methode
<implementatie>
methodes
constructor

Op dit moment lukt het mij een basis object te maken als volgt

JavaScript:

//interface
var TControl = Object.Create(null);

//properties
TMyProperty._name = '';

//properties methodes
Object.defineProperty(TControl,'name', {
    get: function() { return this._name; },
    set: function(value) { this._name =value;
              doeits();
        }
});

//implementation

//methodes
TControl.doiets = function() {
   alert('ik ben een control');
}

//constructor
TControl.create = function() {
  control = Object.create(TControl);
  control.name = 'een nieuwe control';
  return control;
}

/////////////////////

//Aanroep methode:
Control = TControl.create();

Ik heb twee korte vragen, waarbij ik de bekende prototyping buiten beschouwing wil laten:
vraag 1
- Hoe definieer je ipv TControl._name een property met defineProperty;
vraag 2
- Hoe erf ik een defineProperty set over;

[ Voor 1% gewijzigd door RobIII op 16-05-2013 18:13 . Reden: Code tags toegevoegd ]

[NMe]

Waarom zou je in hemelsnaam prototyping buiten beschouwing willen laten in een prototyped language, waarbij je alternatief niet alleen veel meer code oplevert (die allemaal over de lijn moet naar je eindgebruiker) maar bovendien ook nog eens volledig procedureel is?

[MueR]

Javascript mag in Webdesign, Markup & Clientside Scripting

[BoringDay]

NMe schreef op donderdag 16 mei 2013 @ 17:35:
Waarom zou je in hemelsnaam prototyping buiten beschouwing willen laten in een prototyped language, waarbij je alternatief niet alleen veel meer code oplevert (die allemaal over de lijn moet naar je eindgebruiker) maar bovendien ook nog eens volledig procedureel is?

Om het simpel te houden, ik heb hier aardig wat broncode van componenten die in een OOP omgeving zijn ontworpen. Het lijkt me eenvoudiger om een vast structuur aan te houden waarbij de logica overeenstemt.
Dit is ook helemaal niet bedoeld voor een eindgebruiker maar slechts een kwestie van of het mogelijk is.
Voor mij biedt het een hoop voordelen en veel tijd, meer code betekent niet altijd dat het slechter is.
Maar zoals ik al aangaf het gaat mij om wat er mogelijk is, type/class principe te simuleren.

[ Voor 47% gewijzigd door BoringDay op 16-05-2013 18:05 ]

[NMe]

BoringDay schreef op donderdag 16 mei 2013 @ 17:47:
[...]

Daar heb ik verschillende redenen voor.
- structuur aan code en overzicht;

Die is juist elegant bij prototyping.

- onderscheid tussen interface en implementatie wil maken;

En dat kan bij prototyping niet omdat....?

- een functie in javascript ook slechts een object is;

Klopt, maar hoe is dat relevant voor de vraag of je nou wel of niet prototyping toe wil passen?

- ik denk Object toch een wezenlijke doelstelling heeft en keywords als protected niet voor niks zijn gereserveerd;

Ik denk dat je de plank keihard misslaat door te veel vast te houden aan hoe het in Delphi werkt en te weinig open te staan voor de alternatieven die javascript native biedt.

Los van die discussie: ik snap je eerste vraag niet. Wat je tweede vraag betreft: elk object in javascript heeft toch gewoon een inherits-method?

[BoringDay]

NMe schreef op donderdag 16 mei 2013 @ 17:57:
[...]

Die is juist elegant bij prototyping.

[...]

En dat kan bij prototyping niet omdat....?

[...]

Klopt, maar hoe is dat relevant voor de vraag of je nou wel of niet prototyping toe wil passen?

[...]

Ik denk dat je de plank keihard misslaat door te veel vast te houden aan hoe het in Delphi werkt en te weinig open te staan voor de alternatieven die javascript native biedt.

Los van die discussie: ik snap je eerste vraag niet. Wat je tweede vraag betreft: elk object in javascript heeft toch gewoon een inherits-method?

Het kan heel goed zijn dat ik keihard de plank mis sla en als dat zo is, prima daar heb ik totaal geen probleem mee. Lukt het wel, dan is het heel fijn. In beide gevallen zal ik mijn antwoord krijgen.
Overigens is dit ook niet voor een eindgebruiker, slechts een case study.

Om op de eerste vraag te komen:

JavaScript:

Ik maak een object aan
var TControl = Object.create(null);

Hier definieer ik een property
TControl._name <- is er een betere of andere methode zonder de methode als hieronder aangegeven.

Dit kan namelijk ook niet als je Object.create toepast.
TControl.prototyping._name = function() {
} 

[ Voor 4% gewijzigd door BoringDay op 16-05-2013 18:24 ]

[NMe]

Voor zover ik weet is daar zonder prototyping geen kortere manier voor. Wel een langere met __defineGetter__ en __defineSetter__ maar daar heb je ook niks aan.

[BoringDay]

het ging mij alleen om TControl._name.

betreft vraag 2 , die overerving werkt niet correct.
Stel je maakt een nieuwe object aan van TControl en je herdefinieert _name.

Dan komt de trigger uit de functie van TControl niet mee.
Hoe kan je dan in het nieuwe component een inherited op de property uitvoeren?

[NMe]

BoringDay schreef op donderdag 16 mei 2013 @ 18:55:
het ging mij alleen om TControl._name.

Nou begrijp ik je helemaal niet meer? Wat is je probleem nou? Dat je die moet declareren?

betreft vraag 2 , die overerving werkt niet correct.
Stel je maakt een nieuwe object aan van TControl en je herdefinieert _name.

Dan komt de trigger uit de functie van TControl niet mee.
Hoe kan je dan in het nieuwe component een inherited op de property uitvoeren?

Je kan geen property inheriten, je inherit van een heel object, zoals dat in elke OO-implementatie gebeurt (met uitzondering van traits, maar die kent JS niet).

Met andere woorden:

JavaScript:

var myObject = {
    foo:function() {
        alert('bar');
    }
};

var myObject2 = {
    baz:function() {
       alert('qux');
    }
}.inherits(myObject);

myObject.foo(); // bar
myObject.baz(); // fout
myObject2.foo(); // bar
myObject2.baz(); //qux

Bovenstaande even uit het hoofd, ongetest, en dus mogelijk syntactisch niet helemaal juist. Het gaat om het idee.

Over welke trigger heb je het überhaupt?

[BoringDay]

Het idee is volledig duidelijk, dit is ook precies wat ik zocht.
Ben veel vreemde en onoverzichtelijke constructies tegen gekomen.

ik neem aan je ook weer een object kan koppelen aan een property?
zoals bijv. iets in een vorm als dit?

JavaScript:

 var myObject2 = { 
       this.object = new myObject; 
 }

[NMe]

Dat kan (en inderdaad op die manier), maar dat heet geen koppelen, dat is gewoon een attribuut-definitie. Een attribuut kan een primitief type zijn, maar ook gewoon een (al dan niet door jou gemaakt) object.

Ik zeg overigens bewust "attribuut" en niet "property" want JS-objectattributen zijn anders dan wat bijvoorbeeld in C# een property heet.

[crisp]

JS prototypal inheritance is zoiets als dit:

JavaScript:

function Car()
{
    this.maxSpeed = 140;
}
Car.prototype.getMaxSpeed = function()
{
    return this.maxSpeed;
}

function SuperCar()
{
    this.maxSpeed = 300;
}
SuperCar.prototype = new Car(); // of SuperCar.prototype = Object.create(Car.prototype);

var mycar = new Car();
alert(mycar.getMaxSpeed()); // 140
alert(mycar instanceof Car); // true
alert(mycar instanceof SuperCar); // false

var yourcar = new SuperCar();
alert(yourcar.getMaxSpeed()); // 300
alert(mycar instanceof Car); // true
alert(mycar instanceof SuperCar); // true

Overigens heb ik nog nooit gehoord van inherits in JS; zal wel een framework dingetje zijn gok ik

[BoringDay]

Duidelijk, inherited keyword werkt zo te zien zelf in JS niet (die zitten gewoon helemaal in me gestampt).

Ik heb mijn syntax net iets anders, maar komt volgens mij op hetzelfde neer?

JavaScript:

var TElement = function() {
    this.name = 'element';
}
TElement.prototype = new TWhatever;

[crisp]

Jep, komt op hetzelfde neer

[BoringDay]

Als jullie het niet erg vinden, ik weet zeker dat ik straks nog een aantal vragen ga stuiten die ik hier zal plaatsen.
In OOP bestaat het begrip constructor en destructors, normaal gesproken pas ik die toe als ik:
constructor: iets wil initialiseren, sub classes wil aan maken
destructor: als ik iets wil automatisch vrijgeven. (dit is bij js niet nodig, zover ik weet)

Voor een simulatie van een constructor om properties te initialiseren heb ik het volgende model genomen,
en dit werkt ook zoals ik het zou verwachten.
Wat is jullie voorkeur om objecten te initialiseren?

JavaScript:

var TControl = function(){

/*properties*/
    Object.defineProperty(this,"element",{
        "get": function() { return this._element; },
        "set": function(value) { this.setId(value); }});

    Object.defineProperty(this,"id",{
        "get": function() { return this._id; },
        "set": function(value) { this.setId(value); }});

    Object.defineProperty(this,"name",{
        "get": function() { return this._name; },
        "set": function(value) { this.setName(value); alert(this._name); }});

    Object.defineProperty(this,"classname",{
        "get": function() { return this._className; },
        "set": function(value) { this.setClassName(value); }});

    Object.defineProperty(this,"cursor",{
        "get": function() { return this._cursor;},
        "set": function(value) { this.setCursor(value); }});

    Object.defineProperty(this,"color",{
        "get": function() { return this._color;},
        "set": function(value) { this.setColor(value); }});
        
/*constructor*/
    this.constructor = function() {
         this._name = 'koekje'; //does not trigger name property
         this.name  = 'hapje'; //does trigger name property
    }; this.constructor(); 

}

[BoringDay]

Nog een tweede vraag:

stel ik heb een object TFont.
daarnaast wil ik een TControl object maken met een attributen/propertie
this._font = new TFont.

Nu wil ik met this._font.parent = this definieren zodat ik altijd weet vanuit TFont bij welk object die behoord.
Normaal gesproken zou ik een parent assignen (een verwijzing naar de parent, niet een kopie).
Wat doet javascript als ik this._font.parent = this; ?
Als deze een copy maakt dan is dit in mijn optiek een verkeerde methode, is er dan een mogelijkheid om een verwijzing te maken?


------
this.parent = anotherObject is een assignment.

Maar nu stuit ik tegen wat anders aan
Stel ik heb een object TFont.
Ik maak een class TControl met this.font = new TFont;
Vervolgens maak ik
var Control = new TControl
var Control1 = new TControl

Als ik nu een eigenschap van this.font wijzig bij Control, treed deze wijziging ook op
bij Control1. Het lijkt er dan op dat bij New ook geen nieuwe object wordt gemaakt maar slecht een referentie naar 1 object.

Wat ik wil is dat Control een font met eigen waarden heeft en
Control1 een font met eigen waarden heeft.

Hoe gaat dit dan in zijn werk?

[ Voor 39% gewijzigd door BoringDay op 17-05-2013 19:38 ]

[R4gnax]

BoringDay schreef op vrijdag 17 mei 2013 @ 18:19:
Hoe gaat dit dan in zijn werk?

Begin eens met je classes zinnig op te bouwen. Misschien via een simpele class factory:
R4gnax in "[js] Interfaces, handige oplossing zo?"

Daar wordt je code een stuk schoner en simpeler van.

JavaScript:

var TFont = Class.create({
  constructor : function( parent ) {
    this.parent = parent;
  }
});

var TControl = Class.create({
  constructor : function() {
    this._font = new TFont( this );
  }
});

Overigens zou ik je ook aanraden om je aan de heersende casing conventions voor JS te houden, ipv de Delphi conventies door te drukken.

[BoringDay]

Daar had ik vandaag nog wat over gelezen maar Class alleen werd er niet uitgelegd hoe men aan Class kwam.

Het is inderdaad een stuk netter maar als je een volledige library wil maken ontkom je ook niet aan sub items in een object, tenzij je 1000den regels extra wil schrijven.

[BoringDay]

maar define is browser/os specifiek? hier wordt het niet herken

[RobIII]

BoringDay schreef op vrijdag 17 mei 2013 @ 16:37:

BoringDay schreef op vrijdag 17 mei 2013 @ 18:19:

BoringDay schreef op vrijdag 17 mei 2013 @ 20:36:

BoringDay schreef op vrijdag 17 mei 2013 @ 21:16:

BoringDay: Gebruik a.u.b. de edit-link (rechtsbovenaan je post) als je iets toe te voegen hebt; je topic herhaaldelijk omhoogschoppen is niet nodig en die melding staat er niet voor niets:

[ Voor 5% gewijzigd door RobIII op 17-05-2013 21:41 ]

[BoringDay]

Mijn excuus, ik kan ook niet weten dat het forum zo ontworpen is, toch?
Maar het lijkt me volstrekt onlogisch als ik op iemand anders reageer bovenin ga editen ...

[Afvalzak]

BoringDay schreef op vrijdag 17 mei 2013 @ 21:37:
Mijn excuus, ik kan ook niet weten dat het forum zo ontworpen is, toch?
Maar het lijkt me volstrekt onlogisch als ik op iemand anders reageer bovenin ga editen ...

Het gaat ook voornamelijk om 2 berichten achter elkaar aan van jezelf

[RobIII]

BoringDay schreef op vrijdag 17 mei 2013 @ 21:37:
Mijn excuus, ik kan ook niet weten dat het forum zo ontworpen is, toch?
Maar het lijkt me volstrekt onlogisch als ik op iemand anders reageer bovenin ga editen ...

Dan moet je 't linkje in m'n post even beter lezen

Je probleem binnen 24 uur met een 'schopreactie' onder de aandacht brengen. Als je iets nieuws toe te voegen hebt aan je topic binnen die 24 uur en je bent zelf de laatste poster, dan kun je je post bewerken.

[BoringDay]

Ik heb geen enkele intentie gehad om iets omhoog te schoppen.
Voor mij part staat het hele bericht onderaan, aanname's zijn slechts conclusies met een verkeerde interpretatie.

[Erwin537]

Kan je dan misschien niet beter werken met typescript? http://www.typescriptlang.org/Playground/
Zie vooral het simple inheritance voorbeeld. Veel duidelijkere code, en volgens mij precies wat je wilt.. en het compiled natuurlijk gewoon naar javascript.

[BoringDay]

Ik zal typescript even doornemen.
Mijn doelstelling is slechts een soort van componenten set te maken.
In OOP kan je dan heel eenvoudig met classes, subclasses en type definities werken.

Het probleem treedt naar voren als je Object een basis object een property maak en aangeef
this.font = TFont , waarbij TFont een eigen object is.
Als ik 2x de basis object maak en de kleur van this.font.color wijzig, dan wijzigt die bij alle 2 basis objecten. Iets wat ik helemaal niet wil.

Ik wil dat basis Object1.font.color = rood en Object2.font.color = groen , hij pakt in dit geval de laatste verwijzing groen.

[RobIII]

Nogal wiedes; ze hebben allebei een reference naar 'tzelfde "Font object".

[ Voor 4% gewijzigd door RobIII op 17-05-2013 22:42 ]

[BoringDay]

Maar je zou toch denken als this._font = new TFont, bij elk object die met new definieert een nieuwe object is met zijn eigen waarden? althans dat is mijn verwachting.

[R4gnax]

BoringDay schreef op vrijdag 17 mei 2013 @ 21:16:
maar define is browser/os specifiek? hier wordt het niet herken

De define functie is afkomstig van een loader library die het Asynchronous Module Definition (AMD) patroon implementeert. Een voorbeeld hiervan is RequireJS. Dit stond beiden in de post waar ik je naar toe stuurde al vermeld, dus je hebt niet goed gelezen.

BoringDay schreef op vrijdag 17 mei 2013 @ 20:36:
Daar had ik vandaag nog wat over gelezen maar Class alleen werd er niet uitgelegd hoe men aan Class kwam.

De broncode voor de implementatie van Class.create stond in diezelfde post vermeld, met een gebruiksvoorbeeld (dat ook inheritance laat zien) er bij. Dus; je hebt niet goed gelezen.

BoringDay schreef op vrijdag 17 mei 2013 @ 20:36:
Het is inderdaad een stuk netter maar als je een volledige library wil maken ontkom je ook niet aan sub items in een object, tenzij je 1000den regels extra wil schrijven.

En dat is precies wat er gedaan wordt in het voorbeeld wat in mijn post in deze thread staat. Dus die heb je ook niet goed gelezen.

Als je om hulp vraagt, hou dan ook even je aandacht erbij wanneer je de antwoorden doorneemt, okee?

[BoringDay]

Sorry,
maar krijg al uitleg van iemand die een eenvoudigere manier weet.

[ Voor 75% gewijzigd door BoringDay op 19-05-2013 01:47 ]