public protected and private in javascript

[Florian Bücklers]

Hi,

ich werkel schon seit einiger Zeit an ein Javascript Klassenframework und ich denke ich bin allmählich so weit, das ich es einmal vorstellen möchte und gerne eure Meinung dazu hören würde.

Das ganze ist zu finden auf https://github.com/fbuecklers/js-class
wobei die class.js das Framework enthält und die test.js enthält unittest sind die die api verifizieren. Aber auch einen guten überblick darüber geben was alles so geht.

Aber hier noch ein kleines Codebeispiel:
Object.extend('MyClass', function() {
    private.name = null; //variablen müssen initiiert werden

public.init = function(initName) {
        this.name = initName;
    }

public.getName = function() {
        return this.name;
    }

public.setName = function(newValue) {
        this.name = newValue;
    }
});

MyClass.extend('MyExtClass', function(super) {
    public.init = function() {
        super('test');
    }

public.getName = function() {
        return super.getName() + ' from MyExtClass';
    }
});

var obj = new MyClass('myValue');
obj.getName(); // -> myValue
obj.setName('newValue');
obj.getName(); // -> newValue

var obj = new MyExtClass();
obj.getName(); // -> test from MyExtClass
obj.setName('newTest');
obj.getName(); // -> newTest from MyExtClass

Also was sagt ihr?
Ach ja geht nur in browsern die ecma 5 oder __defineGetter__ und __defineSetter__ supporten also kein ie unter version 9

[Struppi]

ich werkel schon seit einiger Zeit an ein Javascript Klassenframework und ich denke ich bin allmählich so weit, das ich es einmal vorstellen möchte und gerne eure Meinung dazu hören würde.

Über das Thema schreib ich seit längeren an einem Artikel, beiß' ich mir aber seit einem halben Jahr die Zähne daran aus. Mir scheint es, es gibt keine wirklich sinnvolle Lösung für einen sauberen OOP Ansatz in JS. Mathias hat letztens auch darüber etwas geschrieben http://molily.de/weblog/javascript-pseudoklassen bzw. auch hier.

Es gibt also 3. Wege

1. den klassischen über eine normale Objekteigenschaft, so wie du es löst. Ist aber im Endeffekt ein vorgaukeln und birgt die Gefahr des überschreibens des Wertes.

2. Wie es Mathias vorschlägt, die Kennzeichnung als private Variabel anhand eines suffix. Das erschwert zumindest das Überschreiben.

3. oder die Kapselung im Konstruktor. Das bringt aber Geschwindigkeitseinbußen mit sich.

Was mich ein wenig stört, ist die Verwendung der Bezeichnung private, obwohl hier nichts privat ist. Das ist wohl ein ähnlicher Ansatz wie joose?

Ich wollte jetzt mal die Geschwindigkeit vergleichen. Ich hatte mir für meinem Artikel einen Benchmark geschrieben mit dem ich die verschiedenen Ansätze teste. Momentan Mootools, Jooes, mein eigener und das pure JS.

Der Test sieht in JS so aus:

var JS = {name:'js'};  
(function() {  
  
var gID = 0;  
function A() {  
	var privat  = gID++;  
	var myA = 0;  
  
	this.a = function(a) {  
		if(a) myA = a;  
		return myA + '(' + this.name() +')';  
	};  
	this.ID = function() {return privat;};  
	this.name = function() {  
		return 'A(' + this.ID() + ')';  
	}  
  
	this.parent = function() {  
		return 'not able';  
	};  
}  
  
A.prototype = {  
	b: function() { return 'A->b() ' + this.name();},  
	c: function() { return 'A->c() ' + this.name();},  
	d: function(p1) { return p1 + ' A->d() Name:' + this.name(); },  
	e: function() { return ' A->e() ';}  
}  
  
function B() {  
	A.call(this);  
}  
B.prototype = new A();  
  
B.prototype = {  
	c: function() { return 'B->c() '+ A.prototype.c.call(this) ;},  
	d: function(p1, p2) { return p1 + ' B->d() ' + A.prototype.d.call(this, p1, p2) ;}  
}  
function C() {  
	B.call(this);  
}  
C.prototype = new B();  
  
C.prototype = {  
	d: function(p1, p2) { return p1 + ' C->d() ' + B.prototype.d.call(this, p1, p2);}  
}  
JS.B =  A;  
JS.C =  B;  
JS.D =  C;  
  
})();

und folgender Testcode:

  
function _debug(txt) {  
var o = document.getElementById('debug');  
o.innerHTML += txt + '\n';  
}  
  
var c1 = new JS.C();  
var c2 = new JS.C();  
var d = new JS.D();  
  
c1.a('c1');  
c2.a('c2');  
_debug( d.d('halllo', 2)  );  
_debug('ich bin ' + c1.name());  
_debug('ich bin ' + c2.name());  
_debug('mein c() ist: ' + c2.c());  
  
_debug('mein a() ist: ' + c1.a());  
_debug('mein a() ist: ' + c2.a());  
_debug('mein a() ist: ' + d.a());  

Die Ausgabe ist:
halllo C->d() halllo B->d() halllo A->d() Name:A(4)
ich bin A(2)
ich bin A(3)
mein c() ist: B->c() A->c() A(3)
mein a() ist: c1(A(2))
mein a() ist: c2(A(3))
mein a() ist: 0(A(4))

Das würde ich gerne mit deinem Skript machen, aber ich krieg's nicht hin:

var JS_CLASS = {name:'js-class'};  
(function() {  
  
var gID = 0;  
Object.extend('A', function() {  
    private.privat = gID++;  
    private.myA = 0;  
  
    public.a = function(a) {  
        this.a = a;  
    }  
  
    public.ID = function() {  
        return this.myA;  
    }  
  
    public.name = function() {  
        return 'A(' + this.ID() + ')';  
    }  
	public.b = function() { return 'A->b() ' + this.name();}  
	  
	public.c = function() { return 'A->c() ' + this.name();}  
	public.d =  function(p, p2) { return p + ' A->d() Name:' + this.name() + '.' + p2; }  
	public.e = function() { return ' A->e() ';}  
  
});  
  
A.extend('B', function(super) {  
    public.init = function() {  
        super('test');  
    }  
  
    public.c = function() {  
        return 'B->c() ' + super.c();  
    }  
    public.d = function(p1, p2) {  
        return p1 + ' B->d() ' + super.d(p1, p2) ;  
    }  
});  
  
B.extend('C', function(super) {  
    public.init = function() {  
        super('test');  
    }  
  
    public.d = function(p1, p2) {  
        return p1 + ' C->d() ' + super.d(p1, p2) ;  
    }  
});  
  
  
JS_CLASS.B =  A;  
JS_CLASS.C =  B;  
JS_CLASS.D =  C;  
  
})();  

Ausgabe:
halllo C->d() halllo B->d() halllo A->d() Name:A(0).2
ich bin A(0)
ich bin A(0)
mein c() ist: B->c() A->c() A(0)
Dann komt eine Fehlermledung: c1.a is not a function

Offensichtlich kann man nicht, von C über B auf eine Funktion in A zugreifen. Da stimmt etwas mit der Vererbungskette nicht.

Struppi.

[jobo]

Hallo,

Blöde Frage: ist von Crockfordhierzu nicht schon "alles" gesagt? (;-)

ich werkel schon seit einiger Zeit an ein Javascript Klassenframework und ich denke ich bin allmählich so weit, das ich es einmal vorstellen möchte und gerne eure Meinung dazu hören würde.

Frameworks sollten vermutlich immer im Vergleich zu bestehenden gesehen werden wie von matthias u.a. beschrieben

Über das Thema schreib ich seit längeren an einem Artikel, beiß' ich mir aber seit einem halben Jahr die Zähne daran aus. Mir scheint es, es gibt keine wirklich sinnvolle Lösung für einen sauberen OOP Ansatz in JS.

Crockford spricht doch auch von der "pseudoclassical method", oder? Und dann taucht doch immer wieder auf, dass es sich um eine "funktionale Programmiersprache" handelt. Und Crockford beschreibt doch auch, wenn ich das recht entsinne, wie sich Sicherheitskonzepte realisieren (das ist ja sein Thema immer wieder) lassen, in dem Funktionen zB. callback-Funktionen als Paramter übergeben bekommen. Vielleicht beißt du dir ja die Zähen aus, weil die Konzepte von private und public eben so 1:1 nicht umsetzbar bzw. eben anders umsetzbar sind?

Gruß

jobo

[jobo]

Hallo,

und dann ist da noch Mathias Übersetzung von soshnikovs Artikel zum Javascript-Core mit Verweisen auf Soshnikovs Artikel zur generellen OOP Theorie mit Bezug auf Javascript und der Implementation von OOP in Ecmascript.

Gruß

jobo

[Florian Bücklers]

Hi,

mir sind die OOP konzepte durchaus bekannt, aber ich bin noch mit keinem richtig glücklich geworden. Ich finde das Thema ist noch solange nicht erschöpft solange man nicht wirklich OOP in JS schreiben kann.

Vielleicht beißt du dir ja die Zähen aus, weil die Konzepte von private und public eben so 1:1 nicht umsetzbar bzw. eben anders umsetzbar sind?

Hm ich finde habe diese Konzepte in meinem Framework schon ziemlich gut umgesetzt bekommen. Also würde ich schon sagen das es durchaus möglich ist.

Grüße Flo

[peterS.]

Hallo Florian,

mir sind die OOP konzepte durchaus bekannt, ...

welche "konzepte" sind das?
und beziehst Du Dich damit auf JavaScript oder allgemein auf OOP?
und meinst Du mit »konzepte« nicht doch eher programmierparadigmen?

... ich bin noch mit keinem richtig glücklich geworden.

was vermisst Du denn - und wo?

Ich finde das Thema ist noch solange nicht erschöpft, ...

das stimmt wohl. darueber liesse sich stundenlang diskutieren,
philosophieren, streiten ...

solange man nicht wirklich OOP in JS schreiben kann.

was ist »wirkliche OOP« ?
wo ist JavaScript nicht OO?
oder wie saehe »wirkliche OOP« in JavaScript aus?

kampfeslustige gruesse.

so long - peterS. - [e-mail]

[Florian Bückkers]

Hi,

und meinst Du mit »konzepte« nicht doch eher programmierparadigmen?

Ähm ja wenn du so willst ;-)

... ich bin noch mit keinem richtig glücklich geworden.

was vermisst Du denn - und wo?

Konzeptinell gibt es ja schon einige FRameworks dir durchaus schon viele weiter Konzepte aus der OO-Welt nach JS bringen, aber ich fin gerade die benutzung ist oft nicht selbsterklärend oder einfach Umständlich

was ist »wirkliche OOP« ?
wo ist JavaScript nicht OO?
oder wie saehe »wirkliche OOP« in JavaScript aus?

Darüber hatte ich heute auch eine etwas längere diskussion mit einem Studienkolegen, (der auch einer der initiator meines Frameworks war) und wir sind zu dem Schluss gekommen das meine Formulierung wohl ein bischen Misslungen war^^ Also du hast Recht JS als "nicht wirklich OOP" zu beschreiben wird der Sprache nicht wirklich gerecht. Sie ist anders als die üblichen statischen OOP Programmiersprachen (liegt wohl daran das sie nicht statisch ist :-P) und ist wohl auch deswegen einer meiner Lieblingsprachen.
Nur manchmal fehlen mir halt dann doch die statischen Strukturen und Konzepte aus anderen Sprachen und wollte diese möglischst "Original" getreu nachbauen. Also ein Programmier, der aus der C# oder Java Welt kommt soll möglichst sofort seine bekannten Strukturen identifizieren und verwenden können.

kampfeslustige gruesse.

Die gebe ich doch gleich mal zurück :-)

[peterS.]

hallo again Florian,

kampfeslustige gruesse.
Die gebe ich doch gleich mal zurück :-)

naja, so richtig kaempfen willst Du aber nicht.

... ich bin noch mit keinem richtig glücklich geworden.
»»
was vermisst Du denn - und wo?

»»

Konzeptinell gibt es ja schon einige FRameworks, ...

z.b.?

... die durchaus schon viele weiter Konzepte aus der OO-Welt ...

welche OO-Konzepte sind das denn, ...

... nach JS bringen, ...

... die JS nicht unterstuetzt?

aber ich finde gerade die benutzung ist oft nicht selbsterklärend
oder einfach Umständlich.

eben genau darum geht es - warum laesst sich eine bestimmte art
von JavaScript-bibliotheken, die sich nicht am DOM abarbeiten,
nur aeusserst sperrig handhaben. worin gleichen sie sich, was
unterscheidet sie voneinander - worin unterscheiden sich die
moeglichkeiten solcher bibliotheken von denen, die der sprach-
kern ohnehin mitbringt?

was ist »wirkliche OOP« ?
wo ist JavaScript nicht OO?
oder wie saehe »wirkliche OOP« in JavaScript aus?

»»

Darüber hatte ich heute auch eine etwas längere diskussion ...
mit einem Studienkolegen ... Sie ist anders als die üblichen
statischen OOP Programmiersprachen... Nur manchmal fehlen mir
halt dann doch die statischen Strukturen...

hm... statisch vs nicht statisch (also dynamisch) ist vielleicht
das schwaechste argument, um sprachen OO-faehigkeit zuzugestehen
oder abzusprechen.

... und Konzepte aus anderen Sprachen.

welche denn nun, lass es Dir doch nicht so aus der nase ziehen.

und wollte diese möglischst "Original" getreu nachbauen.
Also ein Programmier, der aus der C# oder Java Welt kommt,
soll möglichst sofort seine bekannten Strukturen identifizieren
und verwenden können.

aha ... C#, Java ... Du benötigst also Kapselung und Vererbung?
genauer gefragt - Du vermisst die klassenbasierte Vererbung
statischer Sprachen?

warum willst Du JavaScript in einen engen eintoenigen raum zwingen?

in welchem umfeld ist man gezwungen mit JS objektsysteme mit einer
klassischen vererbungshirarchie ueber deutlich mehr als 2 ebenen
aufzubauen?

so long - peterS. - [e-mail]

--
»Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - Douglas Crockford

ie:( fl:) br:> va:( ls:& fo:) rl:) n3;} n4:} ss:} de:µ js:} mo:? zu:]

[jobo]

Hallo,

--
»Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies.
Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.« - Douglas Crockford

Und ließe sich das auch an meinem Beispiel verdeutlichen? Was an dem Ansatz ist richtig, was ist murx?

Zudem habe versucht, das Thema OOP, statische Klassen und Lisp/Javascript(=Lisp in Cs Clothing) nochmal versucht https://forum.selfhtml.org/?t=203493&m=1375996.

Gruß

jobo

[Florian Bücklers]

hi,

kampfeslustige gruesse.
Die gebe ich doch gleich mal zurück :-)

naja, so richtig kaempfen willst Du aber nicht.

Tut mir ja leid aber ich habe viel am Hut zur Zeit

aha ... C#, Java ... Du benötigst also Kapselung und Vererbung?
genauer gefragt - Du vermisst die klassenbasierte Vererbung
statischer Sprachen?

Ja in der Tat, obwohl ich Projekte in kleineren Rahemn auch gerne
mit den Bordmitteln von Javascript umsetzte. Aber gerade in größeren
Projekten erschwert eine nicht statische struktur doch die Lesbarkeit
und die Wartbarkeit von Code. Ich fin Javascript genial wenn man schnell
mal hier und da kleinere Funktionalitäten auf einer Webseite umsetzen
will. Aber wenn man Anfängt wirklich einen Großen Funktionsumfang
umzusetzen erschweren die nicht vorhandenden statischen Strukturen das
Programmieren doch sehr, so dass man eigentlich zwansgläufig auf ein
Framework zurückgreift, dass ein scopse kapselung und eine statische
Vererbung bereitstellt.

Zumal kenne ich mindestens so viele Webentwickler wie Java Entwickler
und mir ist doch aufgefallen das sich die Mehrheit in statischen vorgegebenen
Strukturen wohler fühlen als in so einer dynamischen Welt wie Javascript
sie ein bieten kann.

warum willst Du JavaScript in einen engen eintoenigen raum zwingen?

Ho moment da hast du mich aber doch sehr missverstanden. Ich will JS
höchstens erweitern, aber ihm seine Natur doch nicht nehmen.

Aber vieleicht ist man ja auch als Javascript Programmierer ein wenig Eitel
und Stolz darauf das man die vielen dynamischen Konzepte in gegensatz zu anderen
Programmieren durschaut hat und deshalb die die statische Welt garnicht in JS
haben will.

in welchem umfeld ist man gezwungen mit JS objektsysteme mit einer
klassischen vererbungshirarchie ueber deutlich mehr als 2 ebenen
aufzubauen?

Naja aus dem Potential ergeben sich die Möglichkeiten, das hat die
Vergangenheit schon oft gezeigt. Und ich find gerade jetzt wo das Web
immer mehr kann voralledem die Browser, Entwicklern, ein immer größer
werdenden Funktionsumfang zur Verfügung stellen, sehe ich eigentlich
keinen ausweg als, dass die Objektsysteme in JS immer mehr wachsen
und komplexer werden.

Und währe da nich eine statische Vererbungshierarchie nicht eine
großartige Erweiterung von JS. Nicht ohne grund sind private, protected
public sowie super und class weiterhin reservierte Worte der ECMA5 spec

Grüße Flo

[peterS.]

gruss Flo,

kampfeslustige gruesse.
Die gebe ich doch gleich mal zurück :-)

naja, so richtig kaempfen willst Du aber nicht.

Tut mir ja leid aber ich habe viel am Hut zur Zeit

lass mal gut sein. Du stellst Dich auf mehreren ebenen einer
grundsatzdiskussion, obwohl Du nicht gerade sanft angefasst
wurdest und Deine arbeit noch nicht umfassend gewuerdigt bzw.
zerrissen oder auch nur ignoriert wurde.

aha ... C#, Java ... Du benötigst also Kapselung und Vererbung?
genauer gefragt - Du vermisst die klassenbasierte Vererbung
statischer Sprachen?

Ja in der Tat, obwohl ich Projekte in kleineren Rahemn auch gerne
mit den Bordmitteln von Javascript umsetzte. Aber gerade in größeren
Projekten erschwert eine nicht statische struktur doch die Lesbarkeit
und die Wartbarkeit von Code. ...
so dass man eigentlich zwansgläufig auf ein Framework zurückgreift,
dass ein scopse kapselung und eine statische Vererbung bereitstellt.

so schlimm ist das nicht - wirklich grosse JavaScript projekte werden
eher durch die abwesenheit etablierter entwicklungsumgebungen behindert,
die dieser sprache standardbibliothek(en), module und pakete beibiegen.

Zumal kenne ich mindestens so viele Webentwickler wie Java Entwickler
und mir ist doch aufgefallen das sich die Mehrheit in statischen
vorgegebenen Strukturen wohler fühlen ...

und ich kenne Ruby-Goetter und Rails-Entwickler, die heisse affaeren
mit server- und clientseitigem JavaScript haben/hatten, weil es sich
so *vetraut* anfuehlt ;-)

Aber vieleicht ist man ja auch als Javascript Programmierer ein wenig
Eitel und Stolz darauf das man die vielen dynamischen Konzepte in
gegensatz zu anderen Programmieren durschaut hat und deshalb die
statische Welt garnicht in JS haben will.

um gotteswillen ... nein. als "taeglich-brot-frontendler" ist man
absolut geerdet, was den einsatz von JavaScript angeht.

die wirklich geilen sachen der letzten Jahre wurden allesamt von
Ruby-, Phyton-, Erlang- und, ja auch von JavaScript-Entwicklern
angestossen.

Naja aus dem Potential ergeben sich die Möglichkeiten, das hat die
Vergangenheit schon oft gezeigt. Und ich find gerade jetzt wo das Web
immer mehr kann ... , sehe ich eigentlich keinen ausweg als, dass die
Objektsysteme in JS immer mehr wachsen und komplexer werden.

dazu braucht es aber keine klassen. das blaeht. JavaScript ist eine
DELEGATIONssprache. FUNKTIONen sind vollwertige OBJEKTe.

nur auf diesen beiden sprachmerkmalen aufbauend lassen sich die frei
haus gelieferte prototypische VERERBUNG und die funktionale KAPSELUNG
ohne metaprogrammierung um MEHRFACHVERERBUNG ueber TRAITs bzw. MIXINs
aufbohren. EVENTsysteme, wie PUBLISH-SUBSCRIBE oder das meiner meinung
nach elegantere SIGNAL-SLOT-Konzept sind mit dem aufwand eines MODUL-
patterns und eines in ihm gekapselten mixins ebenfalls ohne meta-
prgrammierung machbar. grundlagen der ASPEKT Orientierten Programmierung
giesst man sich ueber [Function.prototype] elegant und einfach ueber
METHOD MODIFIER ein.

mir scheint, dass mit einem verzicht auf klassen auch der starke hang
zur typsicherheit abnimmt.

mit dem konsequenten verzicht auf konstruktoren fuer eigene objekttypen
entfiele in JavaScript auch der irrglaube ueber >>obj.prototype.constructor<<
etwas ueber die natur von >>obj<< zu erfahren<<. sobald mehrfachvererbung
ins spiel kommt, hilft auch >>obj instanceof MyConstructor<< nicht weiter.

eingebaute TYPSICHERHEIT ist ueberschaetzt - nur richtig geschriebene TESTS
messen die qualitaet des codes zuverlaessig.

DUCKTYPING liefert hinreichend genaue angaben darueber, was ein objekt kann.
der >>typeof<< operator sowie >>Object.prototype.toString.call(obj)<< sind
wasserdichte indikatoren fuer die in JavaScript eingebauten Kernobjekte.

in diesen grundlagen steckt enorm viel potential. man sollte die intelligenz
von klassisch geschulten programmierern nicht beleidigen, indem man ihnen
immer wieder dieselbe kost vorsetzt. ausserdem bin ich der meinung, dass
die menge X an produzierten code in einer zeit Y mit naturnah gekloeppelten
JavaScript sich nicht wesentlich von der unterscheidet, die auf einem
klassenemulierenden framework aufsetzt. man muss sich einarbeiten. trotzdem
schreibt man auch dort immer noch JavaScript. ausserdem laesst man sich, ob
man will oder nicht, auf einen anstrengenden dauerspagat zwischen der wahren
natur dieser sprache und dem was das framework ihr vorgibt zu sein ein.

entscheidend fuer einen effektiven code output in grossen teams und/oder auf
grossen JavaScript-projekten ist dann doch eher die IDE.

Und währe da nich eine statische Vererbungshierarchie nicht eine
großartige Erweiterung von JS. Nicht ohne grund sind private, protected
public sowie super und class weiterhin reservierte Worte der ECMA5 spec

polemik: dass ist nur altlast, die zum glueck verhindert, dass exakt dieses
wording durch pseudoklassische vererbungstrojaner mit falschen versprechungen
von hinten wieder in JavaScript eingekippt wird.

so long - peterS. - [e-mail]

[peterS.]

gruss in die runde,

mit dem konsequenten verzicht auf konstruktoren fuer eigene objekttypen
entfiele in JavaScript auch der irrglaube ueber >>obj.prototype.constructor<<

-----------------------------------------------^^^^^^^^^^^^^^^^^^^
au backe ... scheiss geschrieben! ...

ueber >>obj.constructor<< bzw. >>obj.constructor.prototype<<

etwas ueber die natur von >>obj<< zu erfahren<<. sobald mehrfachvererbung
ins spiel kommt, hilft auch >>obj instanceof MyConstructor<< nicht weiter.
...

... und dann das posting auch noch falsch in den thread gehangen - ich sollte
so spaet nichts mehr in die tasten hauen.

'schuldigung - peterS.

[molily]

Sie ist anders als die üblichen statischen OOP Programmiersprachen (liegt wohl daran das sie nicht statisch ist :-P) und ist wohl auch deswegen einer meiner Lieblingsprachen.

Was meinst du eigentlich mit statisch? Mutable Objects? Statische Typisierung? Statische Klassen?
Ruby bspw. hat keine mutable Objects, hat Klassen mit public/private/protected-Kapselung, ist dynamisch, aber stark getypt. Die Klassen lassen sich zudem erweitern.

Nur manchmal fehlen mir halt dann doch die statischen Strukturen und Konzepte aus anderen Sprachen und wollte diese möglischst "Original" getreu nachbauen. Also ein Programmier, der aus der C# oder Java Welt kommt soll möglichst sofort seine bekannten Strukturen identifizieren und verwenden können.

Das klingt jetzt vielleicht hart, aber solche Versuche sind dafür verantwortlich gewesen, dass die JavaScript-Programmierung lange Zeit katastrophal war. Solche Versuche sind dafür verantwortlich, dass JavaScript die am häufigsten missverstandene Programmiersprache der Welt ist. Mittlerweile hat man erkannt, dass JavaScript eigene spannende Konzepte hat und dass man diese verstehen und anwenden sollte. Das ist, was Leute wie Crockford seit Jahren versuchen: Nicht JavaScript als minderwertigere Version einer anderen Sprache zu verkaufen, sondern die Unterschiede und Vorzüge zu erklären.

Man kann JavaScript schlicht nicht wie Java programmieren. Dabei kommt letztlich Schmus heraus. Man kann es Java-Programmierern nicht nennenswert vereinfachen, denn JavaScript funktioniert grundlegend anders. Sicher kann man Klassendeklarationen wie in Java aussehen lassen. Wenn sie jedoch irgendwelche realen Probleme umsetzen sollen, werden sie scheitern. Auch mit vielen Hilfsmitteln werden sie es nicht hinbekommen, vernünftigen JavaScript-Code zu schreiben. Das ist einfach meine Erfahrung mit Leuten, die kein JavaScript können und daher versuchen, es wie eine ihnen bekannte Programmiersprache zu schreiben.

Um JavaScript programmieren zu können, muss man JavaScript lernen - so einfach ist es meiner Meinung nach. Mutable Objects, funktionale Programmierung, Funktionsscopes zur Kapselung, prototypische Delegation. Metaprogramming und Metasprachen wie CoffeeScript können einem dabei helfen, diese Konzepte einfach und präzise einzusetzen, ohne den Anschein zu erwecken, man würde etwas ganz anderes als JavaScript programmieren.

Das ist ja gerade die Stärke von JavaScript, dass man verschiedene OOP-Konzepte per Metaprogramming in JavaScript implementieren kann. Gewisse Probleme lassen sich mit einer eigenen Syntax kürzer und übersichtlicher ausdrücken. Das ist alles wunderbar, solange man sich nicht die Illusion macht, dadurch ließen sich die entscheidenden Konzepte von JavaScript wegkapseln und gänzlich andere einführen.

Mathias

[molily]

Und Crockford beschreibt doch auch, wenn ich das recht entsinne, wie sich Sicherheitskonzepte realisieren (das ist ja sein Thema immer wieder) lassen, in dem Funktionen zB. callback-Funktionen als Paramter übergeben bekommen.

Auch hier empfehle ich die Artikel von Soshnikov:
http://dmitrysoshnikov.com/ecmascript/chapter-7-1-oop-general-theory/
Er nimmt die Sichtbarkeitsdebatte ziemlich auseinander und bürstet sie gegen den Strich.

Mathias

[jobo]

Hallo,

Und Crockford beschreibt doch auch, wenn ich das recht entsinne, wie sich Sicherheitskonzepte realisieren (das ist ja sein Thema immer wieder) lassen, in dem Funktionen zB. callback-Funktionen als Paramter übergeben bekommen.

Auch hier empfehle ich die Artikel von Soshnikov:
http://dmitrysoshnikov.com/ecmascript/chapter-7-1-oop-general-theory/
Er nimmt die Sichtbarkeitsdebatte ziemlich auseinander und bürstet sie gegen den Strich.

Darin:

"Before analysis of technical part of OOP in ECMAScript, it is necessary to specify a number of general characteristics, and also to clarify the key concepts of the general theory.

ECMAScript supports multiple programming paradigms, which are: structured, object-oriented, functional, imperative and, in the certain cases, aspect-oriented; but, as article is devoted to OOP, let us give the definition of ECMAScript concerning this essence:

ECMAScript is the object-oriented programming language with the prototype based implementation.

Prototype based model of OOP has a number of differences from the static class based paradigm. Let’s take a look at them in detail."

Leider momentan nur über den Google-Cache erreichbar. Der Server scheint down.

Gruß

jobo

[Struppi]

Also was sagt ihr?

Mittlerweile habe ich deinen Ansatz verstanden.

Die Idee mit den Scopes für private, public, protected erscheint mit genial. Ich hätte aber damit ergebliche Schwierigkeiten, da ich es mir angewöhnt habe private Variabeln so zu nennen wie die Getter/Setter Funktionen und nicht setName/getName (Das ist wohl vor allem in Java Bereich so üblich).

Das funktioniert dann aber nicht mit deinem Framework, weil dann die Funktion überschrieben würde:

  
Object.extend('A', function() {  
    public.a = function(p) {  
        this.a = p;  
    }  
});  
  
var b = new A();  
alert('a() ist: ' + b.a());  
alert('a() ist: ' + b.a());  

Fehler: b.a is not a function

Dann kollidiert dein Skript mit mootools (und anderen FW, die Object.create erzeugen).

Das Problem ist, wenn die Funktion Object.create wie von Crockford verbreitet eingebunden wird, wirft das Skript einen Fehler.

Im Webkitbrowser müssen erst die Schlüsselwörter class und public gegen andere Namen ersetzt werden.

Das ist das Ergebnis meines Benchmarks, der aus einer Funktion besteht, die zwei Instanzen erzeugt und dann fünfmal die Funktion d() aufruft (s. anderes Posting von mir).

Das sind die Zahlen:

js            = Eine Verberbunsghierachie nur mit js
class         = ist deins
joose         = http://code.google.com/p/joose-js/
create/getter = sind zwei Ansätze von mir

FF:
js:............  21ms = 47.619/sek.....
getter:........  69ms = 14.492/sek.....
create:........ 113ms = 8.849/sek......
joose:......... 250ms = 4.000/sek......
class:......... 541ms = 1.848/sek......

Opera:
js:............  20ms = 100.000/sek....
joose:.........  48ms = 41.666/sek.....
create:........  64ms = 31.250/sek.....
getter:........ 107ms = 18.691/sek.....
class:......... 610ms = 3.278/sek......

Webkit
js:............  57ms = 35.087/sek.....
getter:........  81ms = 24.691/sek.....
create:........ 134ms = 14.925/sek.....
joose:......... 148ms = 13.513/sek.....
class:......... 691ms = 2.894/sek......

Alles in allem würde ich sagen, die Idee ist gut. Doch der Versuch OOP Paradigmen mit JS umzusetzen, ist immer mit viel Kosten verbunden. Sehr informativ in dem zusammenhang ist der Blog von Andrea Giammarchi der auch einige Benchmarks gemacht hat und am Ende ebenfalls eine Funktion zum erzeugen von Klassen vorstellt.

Struppi.

[Florian Bücklers]

Hi,

danke schön für deine Anmerkungen ich bin mir noch nicht sicher ob ich alle Performance leaks gefunden habe, zudem habe ich noch geplant das man eine kurzschreibweise für getter und setter einführt die dann in etwa so aussieht

Object.extend('MyClass', function() {
    public.get.test = function() {
        return test;
    }
    public.set.test = function(value) {
        test = value;
    }
}

greift mn nun über this.test auf eine variable so wird wie üblich der getter aufgerufen. intern würde ich einfach die beiden methoden als getter und setter registrieren

zu Object.create ist mir momentan ein rätsel, da der ansatz im prinzip das gleiche tut... (ich werde dann wohl die übliche implementierung übernehmen)

hm und bei mir funktioniert es im webkit in wei fern es dort ein problem. Mir ist wohl bewust das diese schlüsselwörter eigentlich nicht genutzt werden sollen. Aber das es wohl bald einen ecma 6 (oder falls der mal wieder gesprengt wird ein 7ner oder 5.1) standard geben wird, der ein klassenkonzept einführt halte ich doch für sehr realitätsfern.

und ich hoffe ich bekomme noch einen performance bust hin bin auch noch nicht ganz zufrieden mit den aktuellen werten aber das war mir auch schon bewusst. Aber ich wollte generell wissen ob es sich noch lohnt mehr zeit in das projekt zu investieren oder nicht.

Grüße Flo

[molily]

Hallo,

Der Code ist die Umsetzung. Die interessiert erst einmal nicht. Was ist das Konzept? Was ist das Ziel? Was sind die Vorteile? Wie verhält sich das zu gegenwärtigen Umsetzungen?

Du setzt (soweit ich das verstanden habe) Pseudoklassen mit public/private/protected-Sichtbarkeiten um. Okay. Warum? Weil es Gang und Gäbe ist? Weil es JavaScript fehlt? Weil das deiner Meinung nach »richtiges« OOP ist? Was heißt das alles? Wozu braucht man das? OOP umfasst verschiedene Paradigmen für verschiedene Zwecke. Klassen und effektive Sichtbarkeiten gehören nicht zwangsläufig dazu.

Vielleicht fängst du besser mit einem Prosatext über das Konzept an. So sagt das niemandem etwas.

Mathias

[jobo]

Hallo,

Der Code ist die Umsetzung. Die interessiert erst einmal nicht. Was ist das Konzept? Was ist das Ziel? Was sind die Vorteile? Wie verhält sich das zu gegenwärtigen Umsetzungen?

Du setzt (soweit ich das verstanden habe) Pseudoklassen mit public/private/protected-Sichtbarkeiten um. Okay. Warum? Weil es Gang und Gäbe ist? Weil es JavaScript fehlt? Weil das deiner Meinung nach »richtiges« OOP ist? Was heißt das alles? Wozu braucht man das? OOP umfasst verschiedene Paradigmen für verschiedene Zwecke. Klassen und effektive Sichtbarkeiten gehören nicht zwangsläufig dazu.

Vielleicht fängst du besser mit einem Prosatext über das Konzept an. So sagt das niemandem etwas.

Ich finde es ja am Beispiel immer am deutlichsten. Ich habe im Rahmen der Schul-Ag mal versucht, mit Javascript (xmtHTTP) und JSON eine Tabelle vom Server zu laden und diese mit "bearbeiten"-Buttons zu versehen. Ich habe vier Objekte:

1. DomCreator
2. InOutHandler
3. AjaxObjekt
4. ActionController

Ich finde, dass es schon jetzt nicht mehr ganz so übersichtlich ist, und dabei sind die "bearbeiten"-button-Funktionen noch nicht mal ausgeschrieben. (Immerhin ist der Code Jslint-konform (;-)).

An Sicherheit oder private Variablen denke ich zur Zeit garnicht, weiß auch nicht, wo ich die wirklich brauchen würde, außer eben, dass man den globalen Scope nicht mit eigenen Vars überschreibt. Dazu nutze ich dann "my" als Präfix für meine Objekte. Ob ich das ganze in eine selbstauführende Funktion packen sollte, weiß ich nicht. Vielleicht mag sich ja mal jemand den Code anschauen?

  
// Mozilla, Opera, Safari sowie Internet Explorer (ab v7)  
var myDOMCreator = {  
	"buildElementWithTextOrNode" : function (elemName, textOrNode) {  
		var node, elem = document.createElement(elemName);  
		if (typeof textOrNode === "string") {  
			node = document.createTextNode(textOrNode);  
		} else if (typeof textOrNode === "object") {  
			node = textOrNode;  
		}	  
		elem.appendChild(node);  
		return elem;  
	},  
	// third parameter optional (if set "header" creates headerline using "<th>" instead of  
	// "</td>" and the keys instead of values for the contents (column-names)  
	"buildRow" : function (rowAsObject, firstCol, headerOrRow, callback) {  
		var i, controlElement, cellElement, rowElem, cellValue;		  
		cellElement = headerOrRow === "header" ? "th" : "td";  
		rowElem = document.createElement("tr");  
		rowElem.id = headerOrRow === "header" ? "header" : "nr" + firstCol;  
		// row number in first column  
		rowElem.appendChild(this.buildElementWithTextOrNode(cellElement, firstCol));  
		for (i in rowAsObject) {  
			if (rowAsObject.hasOwnProperty(i)) {  
				cellValue = headerOrRow === "header" ? i  : rowAsObject[i];  
				rowElem.appendChild(this.buildElementWithTextOrNode(cellElement, cellValue));  
			}  
		}  
		if (headerOrRow === "header") {  
			controlElement = "bearbeiten";  
		} else {  
			controlElement = this.buildElementWithTextOrNode("button", "bearbeiten");  
			controlElement.onclick = function () {  
				callback(this);  
			};  
		}	  
		rowElem.appendChild(this.buildElementWithTextOrNode(cellElement, controlElement));  
		return rowElem;  
	},  
	"tabelize" : function (table, callback) {  
		var i, nextRow, tableElem;  
		tableElem = document.createElement("table");  
		// header Row  
		tableElem.appendChild(this.buildRow(table[0], "rowNr", "header"));  
		// data  
		for (i in table)  {  
			if (table.hasOwnProperty(i)) {  
				nextRow = this.buildRow(table[i], i, "row", callback);  
				tableElem.appendChild(nextRow);  
			}	  
		}  
		return tableElem;  
	}  
};  
var myInOut = {  
	"actionController" : "",  
	"buttons" : document.getElementById("getselect").getElementsByTagName("button"),  
	"setup" : function (actionController) {  
		this.actionController = actionController;  
		this.setupListeners();  
	},  
	"setupListeners" : function () {  
		var i;  
		for (i = 0; i < this.buttons.length; i += 1) {  
			this.buttons[i].onclick = this.actionController.getTable;  
		}	  
	},  
	"divs" : {  
		"data" :  document.getElementById("data"),  
		"response" :  document.getElementById("response")  
	},  
	"reset" : function (whichDiv) {  
		this.divs[whichDiv].innerHTML = new Date() + "<br>";  
	},  
	"addHTML" : function (string, whichDiv) {  
		this.divs[whichDiv].innerHTML += string + "</br>";	  
	},  
	"addDOMTable" : function (table) {  
		this.divs.data.appendChild(myDOMCreator.tabelize(table, this.actionController.bearbeiten));  
	},  
	"setupUpdateRow" : function (button) {  
		var cellElement, updateButton;  
		cellElement = button.parentNode;  
		updateButton = myDOMCreator.buildElementWithTextOrNode("button", "update");  
		updateButton.onclick = function () {  
			//this ist der button  
			myInOut.actionController.update(this);  
		};  
		cellElement.replaceChild(updateButton, button);	  
	}  
};  
var  myAjax = {  
	"xmlhttp" : new XMLHttpRequest(),  
	"get" : function (getUrl, callback) {  
		this.xmlhttp.open('GET', getUrl, true);  
		this.xmlhttp.onreadystatechange = callback;  
		this.xmlhttp.send(null);  
	}	  
};  
var myActionController = {  
	"type" : "", // json oder html momentan  
	"getTable" : function () {  
		var getType, getUrl;  
		getType = this.innerHTML;  
		myActionController.type = getType;  
		myInOut.reset("data");  
		myInOut.reset("response");  
		getUrl = 'http://html-ag.wvs-berlin.de/JSON/json_objekt_test.php?' + getType;  
		myAjax.get(getUrl, myActionController.onreadystatechange);  
	},  
	"onreadystatechange" : function () {  
		// this bleibt das xmlhttpobjekt  
		myInOut.addHTML("readyState =	" + this.readyState, "response");  
		if (this.readyState === 4 && this.status === 200) {  
			if (myActionController.type === "json") {  
				myInOut.addHTML("<h2>json</h2>", "data");  
				var table = JSON.parse(this.responseText);  
				myInOut.addDOMTable(table);  
			} else if (myActionController.type === "html") {  
				myInOut.addHTML("<h2>html</h2>", "data");  
				myInOut.addHTML(this.responseText, "data");  
			}  
		}  
	},  
	"bearbeiten" : function (button) {  
	// just forwarding for the sake of "dont overrule the action controller"  
		myInOut.setupUpdateRow(button);  
	},  
	"update" : function (button) {  
		/*global alert */  
		alert("noch nicht fertig: " + button);  
	}  
};  
myInOut.setup(myActionController);  

Das ganze ist zu bewundern unter http://html-ag.wvs-berlin.de/JSON/json_tests_6.js.html, bzw. die Serverantworten auf den xmlHttpRequest sind JSON oder html.

Es war Teil des Ansatzes, mal den Unterschied zu demonstieren, wie es ist, den Server das html liefern zu lassen und das nur in den output einzubauen mit innerHTML oder sich die Tabelle als JSON-Objekt zu holen und das Einbauen Javascript zu überlassen. Hier geht es nicht(!) um Browser, bei denen Javascript ausgeschaltet sein könnte (;-).

Vielleicht aber kann man an dem Beispiel ja mal erklären, ob und wenn ja was daran OOP ist und was da fehlt oder unelegant ist (mal unabhängig davon, das YUI oder jquery diese Funktionen zu Teilen bereit stellen). Es geht eben vielmehr ums prinzipielle Verständnis anhand eines Beispiels (weiß nicht, ob das jetzt Thread-Injection ist und ich lieber einen eigenen aufmachen sollte).

Gruß

jobo

[Struppi]

1. DomCreator
2. InOutHandler
3. AjaxObjekt
4. ActionController

Das sind zwar Objekte - vom Namen her - aber die Umsetzung ist keine Objektorientierte. Was sich auch daran erkennen läßt, dass es keinen einzigen Konstruktor gibt und das du nirgends new benutzt. Du erzeugst zwar Objekte, aber nur zur Datenhaltung, nicht um einen Objektorientierten Ansatz umzusetzen.

Ein Grundsatz der OOP lautet: Alles ist ein Objekt!

Das würde für deinen Ansatz bedeuten, du musst noch viel mehr Objekte benutzen. Dein DomCreator() erzeugt DOM Elemente, Tabellen, Tabellenreihen, d.h. da sind noch mindestens drei Objekte mehr enthalten. Wenn man sich dann das Objekt genauer anschaut sieht man Codewiederholungen, da sind sicher auch noch diverse Objekte enthalten.

Ich muss aber zugeben, dass ich bisher ähnlich gedacht habe und solche Multifunktionialen Objekte erzuegt habe, in dem Glauben ich würde OO programmieren. Vermutlich hängt das damit zusammen, dass vieles in JS komplizierter ist, als in anderen Programmiersprachen. Man möchte ungern Klassen bzw. Objekte, auf viele Dateien verteilen, da dies im Rahmen einer Internetseite nicht erwünscht ist. Das führt dazu, dass dann am Schluss  solche monolithischen Blöcke herauskommen.

An Sicherheit oder private Variablen denke ich zur Zeit garnicht, weiß auch nicht, wo ich die wirklich brauchen würde, außer eben, dass man den globalen Scope nicht mit eigenen Vars überschreibt. Dazu nutze ich dann "my" als Präfix für meine Objekte.

Mit deinem Ansatz lassen sich private Variabeln auch gar nicht umsetzen, du hast keinen Konstruktor und die Objekte sind im Prinzip lediglich statische Singleton Objekte, die viel zu viel auf einmal machen.

Wenn ich das Objekt myDOMCreator richtig verstehe (ich habe im Moment nicht geug Zeit um mir den ganzen Code anzuschauen), dann ist z.b. die Methode buildRow() eine private Funktion, die nicht von aussen aufgerufen sollte - zumindest ergäbe das keinen Sinn, da der ganze Nutzen, erst innerhalb deiner "Klasse" zur Geltung kommt.

Struppi.

[Florian Bücklers]

Hi,

ich habe jetzt erst wieder die Zeit gefunden zu antworten

Der Code ist die Umsetzung. Die interessiert erst einmal nicht.

Naja ich habe ja ein bischen mehr als nur ein umsetzungscode gepostet, aber mir ging es in erster linie um eure Meinung

Was ist das Konzept?

Nun ja, gerade in größeren Projekten lässt sich javascript nicht so gut strukturieren. Es ist nur schwerlich umzusetzen welche Klasse jetzt was vom wem benutzen soll und darf und welche nicht. Und scopes sind da schon eine bereicherung auf die ich nur ungerne verzichten möchte. Zudem wollte ich eine möglichst kompate und verständiche lösung haben, wie Klassen definiert werden und mich dabei an anderen statischen OO Programmiersprachen orientieren.

Was ist das Ziel?

Ich Arbeite im Rahemn eines größeren Universitären Bachelor und Master Projektes an einem Objekt Persistenz Layer und möchhte in dessen Rahmen auch eine Möglichkeit schaffen Objekte aus Javascript in eine Datenbank zu speichern. Heirfür benötigt man jedoch einige statische Strukturen in JS auf die ich aufbauen möchte.

Was sind die Vorteile?

Was getrennte Scopse und eine nicht prototypische Vererbungshierarchie halt so mit sich bringt (Zumal die prototypische auch noch in meinem Klassenkonzept unterstützt wird). Ich mein ich bin ja nicht der erste der auf die Idee gekommen ist soetwas in JS umzusetzen, mir gefielen die bisherigen Ansätze die ich bis jetzt gesehen habe nicht. Voralledem wie man die Klassen deklariert.

Wie verhält sich das zu gegenwärtigen Umsetzungen?
Nun so weit ist der Entwicklungsstand noch nicht, das ich jetzt schon große Leistungsvergleiche durchgeführt habe. Mir ging es jetzt erstmal nur darum wie es von anderen JS erfahrenden Entwicklern aufgenommen wird, wie Klassen voralledem deklariert und die Vererbungshierarchie genutzt werden kann.

Ich hoffe ich konnte dir und anderen nun ein besseres Bild verschaffen was meine Intentionen waren und sind.

Grüße Flo

[molily]

Nun ja, gerade in größeren Projekten lässt sich javascript nicht so gut strukturieren. Es ist nur schwerlich umzusetzen welche Klasse jetzt was vom wem benutzen soll und darf und welche nicht.

Es ist doch recht überschaubar, denn soviele Möglichkeiten hat JS da nicht. Entweder man setzt Kapselung effektiv über Closures um, dann ist eine Methode immer »private«. Oder man macht sie effektiv »public«, also sie ist ein ganz normaler Member, versieht sie aber mit einem »_«-Präfix oder ähnlich. Dann kann man prinzipiell auf sie zugreifen, aber es ist offensichtlich, dass man es nicht soll.

Klar, mit Gettern und Settern sowie ES5 habe ich jetzt noch mehr Möglichkeiten, den Zugriff effektiv einzuschränken, ohne Closures zu verwenden. Dein Delegator ähnelt wohl am ehesten Proxies in ECMAScript Harmony.

Und scopes sind da schon eine bereicherung auf die ich nur ungerne verzichten möchte.

Ich habe sie in JavaScript noch nie vermisst. Und ich programmiere auch viel mit klassenbasierten Sprachen, in denen Klassen deklariert werden und Kapselung existiert.

Zudem wollte ich eine möglichst kompate und verständiche lösung haben, wie Klassen definiert werden und mich dabei an anderen statischen OO Programmiersprachen orientieren.

Kompakt und verständlich sind m.M.n. auch bestehende Umsetzungen. Nach außen hin unterscheidet sich der Ansatz ja nicht groß von bestehenden Lösungen, die keine Kapselung umsetzen. Nur dass alle Member bei dir über public/private/protected gesetzt werden. PrototypeJS kommt im Grunde mit 30 Zeilen für die Schreibweise Class.create({ init: function () {}, member: ... }); aus plus Methoden-Wrapping für Super-Calls. Das ist natürlich übersichtlicher als folgende Low-Level-Lösung:

function K1 () {  
   var _privateVar = 'K1';  
   this.method1 = function () { alert(_privateVar); };  
}  
K1.prototype.method2 = function () { alert('method2'); };  
  
function K2 () {  
   K1.call(this);  
   var _privateVar = 'K2';  
   this.method3 = function () { alert(_privateVar); };  
}  
K2.prototype.method4 = function () { alert('method4'); };  
[link:http://molily.de/weblog/javascript-pseudoklassen@title=inheritPseudoClass](K1, K2);

Allerdings weiß man hier genau, was getan wird. Es gibt eine Kapselung mit Bordmitteln (Closures) und ansonsten simple prototypische Vererbung. Das mag Programmierer klassenbasierter Sprachen abschrecken, aber im Grunde sind das die Möglichkeiten, die JS bietet. Die kann ich höchstens mit viel Metaprogramming verstecken und in eine »schönere« Form bringen. Dabei gehen sie oft schlicht verloren, sodass man sie durch noch mehr Metaprogramming wieder nachbauen muss.

Ich Arbeite im Rahemn eines größeren Universitären Bachelor und Master Projektes an einem Objekt Persistenz Layer und möchhte in dessen Rahmen auch eine Möglichkeit schaffen Objekte aus Javascript in eine Datenbank zu speichern. Heirfür benötigt man jedoch einige statische Strukturen in JS auf die ich aufbauen möchte.

Ich wüsste nicht, was Serialisierung direkt mit Sichtbarkeiten zu tun hat. In einer größeren Anwendung in einer klassenbasierten Sprache konnten wir die Sichtbarkeiten dazu nicht wiederverwenden. Stattdessen haben wir es so umgesetzt, wie ich es auch in JS umgesetzt hätte: Es gibt deklarativ Metainformationen für den Serializer. In einem public static Hash steht drin, welche Eigenschaften einer Klasse serialisiert werden sollen und ggf. welche Serialisierungsfunktion (ebenfalls public static) verwendet werden soll.

Mathias

[Struppi]

function K1 () {

var _privateVar = 'K1';
   this.method1 = function () { alert(_privateVar); };
}
K1.prototype.method2 = function () { alert('method2'); };

function K2 () {
   K1.call(this);
   var _privateVar = 'K2';
   this.method3 = function () { alert(_privateVar); };
}
K2.prototype.method4 = function () { alert('method4'); };
[link:http://molily.de/weblog/javascript-pseudoklassen@title=inheritPseudoClass](K1, K2);

>   
> Allerdings weiß man hier genau, was getan wird.  
  
Du hast hiermit ein schönes Beispiel geliefert warum das eben nicht ist. Durch die Reihenfolge in den Aufrufen überschriebst du die Funktion method4() und mancher weiß ertsmal üpberhaupt nicht, warum das so ist  
  
~~~javascript
var k2 = new K2();  
k2.method4();  

Fehler: k2.method4 is not a function

Das ist ein Grund, warum ich nicht fertig werde mit meinem zweiten Artikel über OOP.

Struppi.

[molily]

K2.prototype.method4 = function () { alert('method4'); };
inheritPseudoClass(K1, K2);[/code]

Allerdings weiß man hier genau, was getan wird.

Du hast hiermit ein schönes Beispiel geliefert warum das eben nicht ist. Durch die Reihenfolge in den Aufrufen überschriebst du die Funktion method4() und mancher weiß ertsmal üpberhaupt nicht, warum das so ist

Bei dem Beispiel war ich schlicht unaufmerksam, da es mir nur um die groben Konzepte ging. Dass diese simple Helferfunktion nicht universell ist, sollte klar sein. Prinzipiell ließe sie sich auch so schreiben, dass sie diesen Anwendungsfall abdecken könnte (bestehende Member des Prototyps an den neuen kopieren).

Wer sie einsetzt, sollte verstehen, was sie macht. Andernfalls sollte man eine ausgereifte Lösung wie in Mootools oder PrototypeJS einsetzen. Da sieht man nichts von Konstruktoren und Prototypen, sondern ruft bloß eine Methode auf und übergibt ein Object mit sämtlichen Membern. Diese Schreibweise ist idiotensicher, allerdings ist die interne Funktionsweise völlig weggekapselt.

Mathias

[Struppi]

K2.prototype.method4 = function () { alert('method4'); };
inheritPseudoClass(K1, K2);[/code]

Allerdings weiß man hier genau, was getan wird.

Du hast hiermit ein schönes Beispiel geliefert warum das eben nicht ist. Durch die Reihenfolge in den Aufrufen überschriebst du die Funktion method4() und mancher weiß ertsmal üpberhaupt nicht, warum das so ist

Bei dem Beispiel war ich schlicht unaufmerksam, ...

Wie gesagt, es ging um deine Aussage "man weiß genau" - das weiß man eben nicht, sondern es muss höllisch aufgepaßt werden, dass die Reihenfolge stimmt. Und selbst das kann u.U. variieren, je nach Ansatz der Helferfunktion. Es muss als immer völig klar sein, welche Helperfunktion hier verwendet wird und jeder muss dann auch immer Wissen, wie diese funktioniert.

Dass diese simple Helferfunktion nicht universell ist, sollte klar sein.

Ich glaube aus genau dem Grund, hat Florian sein FW entwickelt.

Prinzipiell ließe sie sich auch so schreiben, dass sie diesen Anwendungsfall abdecken könnte (bestehende Member des Prototyps an den neuen kopieren).

Und warum dann nicht gleich eine super Funktion einbauen, wenn man schon dabei ist?
Und was ist mit Mehrfachvererbung?

Wer sie einsetzt, sollte verstehen, was sie macht.

Ja, das dürfte bei fast allen der Fall sein, es geht aber um das Grundkonzept der Sprache.

Letztlich hast du aber Florian bestätigt.

Der Ansatz der Sprache kann Fehleranfällig sein, weil sie so dynamisch ist wie kaum eine andere Sprache. Da der prototype leicht überschrieben werden kann.

Einfach Lösungen können Fehleranfällig sein, wenn man unaufmerksam ist oder das genaue Konzept nicht kennt.

Und komplexe Lösungen sind oftmals verdammt langsam.

Struppi.

[jobo]

Hallo,

Einfach Lösungen können Fehleranfällig sein, wenn man unaufmerksam ist oder das genaue Konzept nicht kennt.

Und komplexe Lösungen sind oftmals verdammt langsam.

Ist YUI langsam? Das ist ja Crockfords Konzept, oder?

Gruß

jobo

[Struppi]

Einfach Lösungen können Fehleranfällig sein, wenn man unaufmerksam ist oder das genaue Konzept nicht kennt.

Und komplexe Lösungen sind oftmals verdammt langsam.

Ist YUI langsam? Das ist ja Crockfords Konzept, oder?

YUI ist keine komplexe Lösung. Es macht nicht viel mehr, wie Mathias in seinem letzten Artikel beschreibt. Es kopiert die prototype Funktion um und damit hat es sich.

Aber ich kann es nicht genau sagen, da ich das Ding nicht zum laufen kriege. Wenn ich das Modul 'oop' einbinden will, krieg ich nur eine Fehlermeldung. Und wenn ich solchen Code in den Beispielen sehe 'anim-drop.html':

<script language="javascript">  
..  
</script>  

.. ist mein Vertrauen zu dem Framework auch erstmal beendet. Auch vom Umfang her ist das ganze wohl eher etwas für die "Enterprise" Entwicklung und kaum zu gebrauchen für den Normalanwender, der ein bisschen Unterstützung für seine Skripte sucht.

Struppi.

[molily]

Wie gesagt, es ging um deine Aussage "man weiß genau" - das weiß man eben nicht, sondern es muss höllisch aufgepaßt werden, dass die Reihenfolge stimmt.

Wenn man weiß, was darin gemacht wird - es wird der Prototyp von Subclass gesetzt, indem ein Objekt erzeugt wird, welches an Superclass.prototype delegiert - dann ist vollkommen klar, warum der Aufruf an genau dieser Stelle und keiner anderen stehen kann.

Ich sehe da keine Unklarheiten. Ja, man muss aufpassen. Warum man aufpassen muss, erklärt sich aber dadurch, dass der Prototyp gesetzt (überschrieben) wird.

Dass diese simple Helferfunktion nicht universell ist, sollte klar sein.

Ich glaube aus genau dem Grund, hat Florian sein FW entwickelt.

Universell ist sein Framework insofern, dass es ein festes Schema vorgibt. Wie gesagt, das leisten andere Implementierungen auch. Y.extend leistet dasselbe wie meine primitive Helferfunktion und kann darüber hinaus noch viel mehr. Durch die Kompaktschreibweise ist das Problem der Reihenfolge aus der Welt.

Und warum dann nicht gleich eine super Funktion einbauen, wenn man schon dabei ist?

Ich habe es nicht gemacht, weil das dazu nötige Function-Wrapping sehr viel Komplexität hinzufügt und Performance kostet. Ich halte das in JavaScript für ein Problem, das man im Einzelfall geschickter lösen kann.

Und was ist mit Mehrfachvererbung?

Mehrfachvererbung ist auch auf die einfache Weise möglich.

Letztlich hast du aber Florian bestätigt.

Der Ansatz der Sprache kann Fehleranfällig sein, weil sie so dynamisch ist wie kaum eine andere Sprache. Da der prototype leicht überschrieben werden kann.

Ich sehe das nicht als Fehler von JavaScript. Ich bin nicht der Ansicht, dass die grundlegendsten Strukturen bereits »sicher« sein sollten. Das würde die Möglichkeiten arg begrenzen. Bei JavaScript ist es Aufgabe des Programmierers, sich selbst Strukturen zu schaffen, die ihm gewisse Regeln auferlegen. Das ist einfach nötig, vor allem wenn man mit vielen Entwickeln an umfangreichem Code arbeitet. Dazu gibt es bereits viele verschiedene Ansätze, je nachdem, welche Anforderungen man hat. Das bedeutet aber nicht, dass jeder Ansatz gleich stimmig ist.

Mathias

[Struppi]

Ich sehe da keine Unklarheiten. Ja, man muss aufpassen. Warum man aufpassen muss, erklärt sich aber dadurch, dass der Prototyp gesetzt (überschrieben) wird.

und genau das ist das Problem, du kannst dir in JS nie sicher sein, dass eine prototype Funktion irgendwo überschrieben wird. Und das wirft Unklarheiten auf.

Du kannst dich drehen und wenden wie du willst, das ist in anderen Sprachen nicht so einfach und macht den Umgang mit Objekten in JS ab einer gewissen komplexität schwierig und erfordert eine grosse Disziplin.

Das ist genau das was durch OOP verbessert werden soll, dass du unter keinen Umständen Eigenschaften und Methoden die einer Klasse gehören manipulieren kannst.

Dass diese simple Helferfunktion nicht universell ist, sollte klar sein.

Ich glaube aus genau dem Grund, hat Florian sein FW entwickelt.

Universell ist sein Framework insofern, dass es ein festes Schema vorgibt. Wie gesagt, das leisten andere Implementierungen auch. Y.extend leistet dasselbe wie meine primitive Helferfunktion und kann darüber hinaus noch viel mehr. Durch die Kompaktschreibweise ist das Problem der Reihenfolge aus der Welt.

Leider kriege ich YUI nicht zum laufen. Wenn ich yui.js lokal einbinde und dann z.b. YUI.use('oop') aufrufe, erhalten eine Fehlermeldung, dass YUI.LANG nicht definiert ist. Wenn ich es vom yahoo Server hole, dann kriege ich hier eine Fehlermledung:

YUI.use('oop', function(Y){  
/*  
Bird und Flighted aus deinen Beispielen  
*/  
Y.extend(Bird, Flighted);  
});  

Fehler: Y.extend is not a function

Und warum dann nicht gleich eine super Funktion einbauen, wenn man schon dabei ist?

Ich habe es nicht gemacht, ...

Das war eher eine retorische Frage, um dich auf die Intention von Florian hinzuweisen.

Denn genau dann beginnen die Probleme, denn wenn du an dieser Stelle eine Super Funktion einbauen wolltest fehlt dir diese aber in den prototype Funktionen die später definiert werden.

Du hättest dann auf jeden Fall ein Timinig Problem. Entweder du rufst deine Vererbungsfunktion vorher auf und verpaßt die prototypen danach oder umgekehrt und überschreibst den prototypen.

Und was ist mit Mehrfachvererbung?

Mehrfachvererbung ist auch auf die einfache Weise möglich.

Wie?
Mir ist kein Weg eingefallen, wie sich eine Mehrfachvererbung in JS wirklich umsetzen läßt. Du kannst Objekte erzeugen denen du die prototype Funktionen mehrer Objekte zuweisen kannst, aber instanceof scheitert in dem Fall.

Letztlich hast du aber Florian bestätigt.

Der Ansatz der Sprache kann Fehleranfällig sein, weil sie so dynamisch ist wie kaum eine andere Sprache. Da der prototype leicht überschrieben werden kann.

Ich sehe das nicht als Fehler von JavaScript. Ich bin nicht der Ansicht, dass die grundlegendsten Strukturen bereits »sicher« sein sollten. Das würde die Möglichkeiten arg begrenzen. Bei JavaScript ist es Aufgabe des Programmierers, sich selbst Strukturen zu schaffen, die ihm gewisse Regeln auferlegen.

Volle Zustimmung, aber wie gesagt, OOP definert eigentlich diese Regeln schon und nimmt dem Programmierer diese Aufgaben ab, deshalb ist dieses Konzept für jemanden der zuerst eine klasissche OO Sprache lernt eben fehleranfällig.

Damit will ich aber nicht sagen, dass das ein Fehler von JS ist. Aber das erklärt warum soviele versuchen JS mehr OO Paradigmen überzustülpen. Ob das nun gut oder schlecht ist, ist letztlich eine Frage wie der einzelne es gewohnt ist zu programmieren. Da ich, als "Liebhaber" von Perl, mich mit ähnlichen Problemen auseinandersetzen muss, fällt mir das nicht weiter schwer. Aber ich denke für jemanden der ansonsten viel mit Java arbeitet, sieht die Sache anders aus.

Struppi.

[molily]

Kurz dazu:

Leider kriege ich YUI nicht zum laufen. Wenn ich yui.js lokal einbinde und dann z.b. YUI.use('oop') aufrufe, erhalten eine Fehlermeldung, dass YUI.LANG nicht definiert ist. Wenn ich es vom yahoo Server hole, dann kriege ich hier eine Fehlermledung:

<script type="text/javascript" src="http://yui.yahooapis.com/3.3.0/build/yui/yui-min.js"></script>
(YUI seed, lädt alle weiteren Module automatisch asynchron per Ajax)

oder

<script type="text/javascript" src="http://yui.yahooapis.com/combo?3.3.0/build/yui/yui-min.js&amp;3.3.0/build/oop/oop-min.js"></script>
(der Kern und das OOP-Modul)

und dann

<script type="text/javascript">
YUI().use('oop', function(Y) {
   // ...
});
</script>

Mathias

[Struppi]

Leider kriege ich YUI nicht zum laufen. Wenn ich yui.js lokal einbinde und dann z.b. YUI.use('oop') aufrufe, erhalten eine Fehlermeldung, dass YUI.LANG nicht definiert ist. Wenn ich es vom yahoo Server hole, dann kriege ich hier eine Fehlermledung:

<script type="text/javascript" src="http://yui.yahooapis.com/3.3.0/build/yui/yui-min.js"></script>
(YUI seed, lädt alle weiteren Module automatisch asynchron per Ajax)

http://selfhtml.jstruebig.de/yui.html

Fehler: y.Lang is undefined
Quelldatei: http://yui.yahooapis.com/3.3.0/build/yui/yui-min.js
Zeile: 8

oder

Der gleiche Fehler. Was mach ich falsch?

Struppi.

[jobo]

Hallo,

Der gleiche Fehler. Was mach ich falsch?

na wie molily schreibt. Du mixed ja Teil 1 und Teil 2 bzw. nutzt wohl bei deiner Resource Y.seed() nicht.

s.a. http://html-ag.wvs-berlin.de/JSON/yui_test.js.html

  
<script type="text/javascript" src="http://yui.yahooapis.com/combo?3.3.0/build/yui/yui-min.js&amp;3.3.0/build/oop/oop-min.js"></script>  
<script type="text/javascript">  
YUI().use('oop', function(Y) {  
   alert(Y.extend);  
});  
</script>  

Gruß

jobo

[Struppi]

Der gleiche Fehler. Was mach ich falsch?

na wie molily schreibt. Du mixed ja Teil 1 und Teil 2 bzw. nutzt wohl bei deiner Resource Y.seed() nicht.

Nein, ich dachte YUI wäre ein Objekt, wie bei jquery, es ist aber ein Funktion.

Struppi.

[jobo]

Hallo,

Der gleiche Fehler. Was mach ich falsch?

na wie molily schreibt. Du mixed ja Teil 1 und Teil 2 bzw. nutzt wohl bei deiner Resource Y.seed() nicht.

Nein, ich dachte YUI wäre ein Objekt, wie bei jquery, es ist aber ein Funktion.

Mh, schau nochmal: http://html-ag.wvs-berlin.de/JSON/yui_test.js.html

Y.extend ist eine Funktion.
Y ist ein Objekt. Du hast das Ressource-Befehl-Paar falsch kombiniert würde ich meinen. Ein alert gibt ja immer was aus, egal ob Funktion oder Objekt. Da gibt es ja deshalb keinen Fehler, dass die Eigenschaft nicht existiert.

Gruß

jobo

[molily]

Nein, ich dachte YUI wäre ein Objekt, wie bei jquery, es ist aber ein Funktion.

YUI ist eine Factory-Funktion, der man ein Hash mit Parametern übergeben kann. Darin lässt sich vor allem der Modul-Loader konfigurieren.

Auf diese Weise lassen sich mehrere asynchrone Scopes mit verschiedenen Dependancies erzeugen. Darüber kann man bspw. auch YUI 2 laden, ohne dass das globale Objekt verschmutzt wird.

http://developer.yahoo.com/yui/3/examples/yui/yui-multi.html

Etwas ähnliches hat jQuery mit jQuery.sub() kürzlich mit 1.5 auch eingeführt. Bei YUI 3 ist es schon im Modulkonzept integriert.

Mathias

[jobo]

Hallo,

Nein, ich dachte YUI wäre ein Objekt, wie bei jquery, es ist aber ein Funktion.

YUI ist eine Factory-Funktion, der man ein Hash mit Parametern übergeben kann. Darin lässt sich vor allem der Modul-Loader konfigurieren.

  
YUI().use('oop', function(Y) {  
   alert(Y.extend);  
	alert(Y);  
});  

~~~.  
  
Woher weiß das "Y" was es ist. Ich übergebe meiner Funktionen einen Parameter, der vorher nicht gesetzt wird. Ist das wie beim eventhandler, wenn ich das onclick = myfunc; hinschreibe und bei function myfunc (myNameForEvent) {} mit "myNameForEvent" den Event bezeichne? Also ident wäre mit myfunc() {myNameForEvent = this;} ?  
  
Gruß  
  
jobo

[jobo]

Hallo,

Hallo,

Nein, ich dachte YUI wäre ein Objekt, wie bei jquery, es ist aber ein Funktion.

YUI ist eine Factory-Funktion, der man ein Hash mit Parametern übergeben kann. Darin lässt sich vor allem der Modul-Loader konfigurieren.

YUI().use('oop', function(Y) {
   alert(Y.extend);
alert(Y);
});

>   
> Woher weiß das "Y" was es ist. Ich übergebe meiner Funktionen einen Parameter, der vorher nicht gesetzt wird. Ist das wie beim eventhandler, wenn ich das onclick = myfunc; hinschreibe und bei function myfunc (myNameForEvent) {} mit "myNameForEvent" den Event bezeichne? Also ident wäre mit myfunc() {myNameForEvent = this;} ?  
  
in function use (...) :  
Y.\_notify(callback, response, args);  
  
in function \_notify:  
  
              callback(this, response);  
  
im Prinzip also:  
  
~~~javascript
  
var MyFactory = function() {  
	var M = {  
		test : "testVar",  
		testfun : function (callback) {  
			callback(this);  
		}  
	}  
	return M;  
}  
MyFactory().testfun(function (a) {  
	alert(a.test);  
});  

Gruß

jobo

[molily]

und genau das ist das Problem, du kannst dir in JS nie sicher sein, dass eine prototype Funktion irgendwo überschrieben wird.

Richtig. Dafür führt ES5 Property Descriptors ein.

Du kannst dich drehen und wenden wie du willst, das ist in anderen Sprachen nicht so einfach und macht den Umgang mit Objekten in JS ab einer gewissen komplexität schwierig und erfordert eine grosse Disziplin.

»Klassen« exakt in JavaScript nachzubauen ist nicht einfach, weil JavaScript nativ keine solchen bietet. Habe ich das irgendwo behauptet? Ich habe den Artikel auch geschrieben, um Pseudoklassen zu problematisieren. Es ist ein Pattern, das in JavaScript nur schlecht als recht mit einem Haufen Overhead umgesetzt werden kann. JavaScript bietet dazu andere Methoden.

Das ist genau das was durch OOP verbessert werden soll, dass du unter keinen Umständen Eigenschaften und Methoden die einer Klasse gehören manipulieren kannst.

In ES3 sind sämtliche Objekte mutable. ES5 ändert das, ohne dass es plötzlich Klassendeklarationen mit Sichtbarkeiten gibt.

Mir ist kein Weg eingefallen, wie sich eine Mehrfachvererbung in JS wirklich umsetzen läßt. Du kannst Objekte erzeugen denen du die prototype Funktionen mehrer Objekte zuweisen kannst, aber instanceof scheitert in dem Fall.

Achso, das meinst du mit Mehrfachvererbung. Klar, es kann immer nur einen Prototyp-Verweis geben und mehrere Prototypen müssen somit in einer Kette liegen.
Gegen Mehrfachvererbung haben sich ja selbst viele klassenbasierte Sprachen entschieden. Dafür gibt es dann flexible Alternativen wie Mixins.

Damit will ich aber nicht sagen, dass das ein Fehler von JS ist. Aber das erklärt warum soviele versuchen JS mehr OO Paradigmen überzustülpen. Ob das nun gut oder schlecht ist, ist letztlich eine Frage wie der einzelne es gewohnt ist zu programmieren. Da ich, als "Liebhaber" von Perl, mich mit ähnlichen Problemen auseinandersetzen muss, fällt mir das nicht weiter schwer. Aber ich denke für jemanden der ansonsten viel mit Java arbeitet, sieht die Sache anders aus.

Natürlich, JavaScript ist eine schwierige, weil flexible Sprache, die einem erst einmal wenig Halt gibt. Man kann viel machen, aber auch viel falsch machen. Deshalb versuche ich, Leuten die Funktionsweise von JavaScript zu erklären und Pattern zu etablieren. Den Versuch, JavaScript für Java-Programmierer attraktiver zu machen, halte ich jedoch für problematisch.

Ansätze wie CoffeeScript sind vielversprechend, um Konventionen zu etablieren und die JS-Programmierung zu vereinfachen. Trotzdem bleibt es eine sehr mächtige Sprache. Was man in purem JS falsch machen kann, kann man auch in CoffeeScript oder Pseudoklassen falsch machen. CoffeeScript ist selbst für mich als Fortgeschrittenen eine »leaky abstraction«, ich muss oft schauen, was für ein JS-Code generiert wird.

Mathias

[Florian Bücklers]

Hi,

hui ihr habt mir das aber ganz schön kompliziert gemacht hier noch zu kommentieren ;-)

Ich glaube aus genau dem Grund, hat Florian sein FW entwickelt.

Jep, Struppi hat mich verstanden ;-). Ich habe nichts gegen die native
Umsetzung von OOP in JS. Aber (tut mir Leid das ich jetzt auch noch mal auf
deinem Beispiel rumhacke molily) das war einfach mal das Paradebeispiel dafür warum ich die nativen Lösungen alle nicht allzu Prickelnd finde.

Ich habe mir deinen Code angesehen und mich auch zuerst gefragt warum er nicht Funktioniert. Ich muss ehrlicher weise zugeben das ich deinen Artikel noch nicht gelesen habe und somit deine inheritPseudoClass Funktion noch nicht kannte. Erst als ich mir die Implementierung agesehen habe wurde mir klar warum method4 nicht existiert.

Das Hauptproblem was ich bei nativen Umsetzung sehe ist, dass man Funktionen aufrufen muss nachdem man seine eigentliche Klassendefinition geschrieben hat, um die Logik seiner Klasse zu Komplettisieren.

So muss man beispielsweise den prototypen seine Klasse nachträglich setzen, oder sich irgendwo Methoden zwischen merken wenn man sie kurz darauf Überschreiben will, aber diese dennoch aufrufen will (super call).

Hat man eine kleinere Wrapper Funktion die diese grundlogick der Vererbung übernehmen, wie deine inheritPseudoClass kommen genau solche Probleme zum Zug
Wann muss ich welche Funktion rufen und wann wo welche Methode deklarieren.

Prototyping ist genial wenn man Funktionalitäten von Bibliotheken oder bestehenden Klassen erweitern will, aber sein Gundlogik so aufzubauen und zusammen zu halten ist jedoch sehr umständlich mit Prototyping.

Jetzt zu den bestehenden Frameworks. Ja durchaus gibt es ein Reihe von Frameworks mit den man ebenfalls seine Klassendefinitionen strukturiert verfassen kann. Aber auch hier habe ich noch keine Variante gefunden bei der man auf dem ersten Blick sieht wo was angegeben und deklariert wird. (Was zwangsläufig zu Missverständnissen und Fehlern führt)
Ich will das mal demonstrieren an der Kompaktschreibweise, die Kommentare habe ich mal absichtlich weggelassen.

  
var Chicken = Y.extend(  
    function (name) {  
        Chicken.superclass.constructor.call(this, name);  
        this.run();  
    },  
    Bird,  
    {  
        this.name = 'test',  
        run: function () {  
            this.sing();  
        },  
        sing : function () {  
            alert("The chicken " + this.name + " says:");  
            Chicken.superclass.sing.call(this, name);  
        }  
    }  
);  

Wer mir hier auf Anhieb sagen kann was hier was zu bedeuten hat, verdient meinen Respekt. Aber der kann mir sicherlich auch erklären warum die Argumentreihenfolge gerade Konstruktor, Elternkonstruktor und dann Members ist. Gut man kann argumentieren in Java schreibt man auch Klasse extends Elternklasse und dann kommt der Klassenrumpf aber man könnte genau anders herum argumentieren, das man in JS üblich erst die Klasse definiert und anschließend die Elternklasse als Prototype setzt.
Ich habe mich im ersten Moment auch über das erste Argument gewundert. Was hat da ein Funktion zu suchen ich will doch von einer bestehenden Klasse Extenden und nicht eine neue definieren. Und was mache ich wenn ich von keiner Klasse erbe? muss ich dann als zweites Argument null angeben oder darf man das weg lassen. Ich wüsste es nicht also erstmal nachschlagen.

Nun worauf ich hinaus will Struktur ist in großen Projekten alles!

Zum Vergleich das selbe mit meinem Framework:

  
Bird.extend(function (super) {  
    public.name = 'test';  
    public.init = function(name) {  
        super(this, name);  
        this.run();  
    }  
    public.sing = function(name) {  
        alert("The chicken " + this.name + " says:");  
        super.sing(name);  
    }  
});  

Nun über sein eigens Werk zu Urteilen ist immer schwer, aber wem schon einmal Klassen in einer typischen OO Programmiersprache über den Weg gelaufen sind, ...

Ich sehe das nicht als Fehler von JavaScript. Ich bin nicht der Ansicht, dass die grundlegendsten Strukturen bereits »sicher« sein sollten... . Bei JavaScript ist es Aufgabe des Programmierers, sich selbst Strukturen zu schaffen...

Hm hier schieden sich wohl die Geister warum muss der Programmierer sich selbst Strukturen schaffen?

Wenn das jeder tun würde und man mit mehreren Leuten an einem Projekt arbeitet, was gibt denn das für ein Wust...

Genau hierfür sind Frameworks da, eine gemeinsame Struktur schaffen auf die man sich einigt. Sie ist generisch und für Neueinsteiger verständlich.

Und wenn man OO Programmierung in JS betreiben will dann kommt man um ein Umfangreicheres Framework nicht darum herum. Wenn man jedoch JS Funktional angeht sieht die Sache ganz anders aus.

So ist ein bisschen länger geworden aber ich komm leider nur Abends dazu meinen Senf dazu zu geben.

Grüße Flo

[jobo]

Hallo,

var Chicken = Y.extend(
    function (name) {
        Chicken.superclass.constructor.call(this, name);
        this.run();
    },
    Bird,
    {
        this.name = 'test',
        run: function () {
            this.sing();
        },
        sing : function () {
            alert("The chicken " + this.name + " says:");
            Chicken.superclass.sing.call(this, name);
        }
    }
);

>   
> Wer mir hier auf Anhieb sagen kann was hier was zu bedeuten hat, verdient meinen Respekt. Aber der kann mir sicherlich auch erklären warum die Argumentreihenfolge gerade Konstruktor, Elternkonstruktor und dann Members ist.  
  
Naja, ohne Lesen der Doku gehts nicht. Auch nicht bei PHPs  Zend-Framework (komplett OOP).  Irgendwie scheinen sich die Erklärungen dazu und Argumente alle auch hier zu finden: <http://www.yuiblog.com/blog/2010/01/06/inheritance-patterns-in-yui-3/>.  
  
YUI bietet ein pseudoklassisches Inheritance-Pattern mit Y.extend(ChildClass, ParentClass). Einfacher gehts doch nicht, oder? Gleichzeitig wird aber auch in dem Artikel auf die prototypische Vererbung eingegangen, wie molily das ja natürlich auch tut, denn da gehts ja auch um YUI.  
  
Mir scheint das Argument "das ist mir zu kompliziert, wir machen das so wie wirs können, das andere ist was für hyperintelligente Freaks, wir müssen das für die Normalos anpassen" nicht stimmig. Crockford beschreibt ja selbst, dass er lange mit Javascript gehadert hat, bis ihm aufgegangen ist, wie man damit umgehen sollte. Im Kern geht es wohl auch auf einer abstrakteren Eben in diesem Artikel darum: <http://javascript.crockford.com/little.html>.  
  
Gruß  
  
jobo

[Struppi]

Wer mir hier auf Anhieb sagen kann was hier was zu bedeuten hat, verdient meinen Respekt. Aber der kann mir sicherlich auch erklären warum die Argumentreihenfolge gerade Konstruktor, Elternkonstruktor und dann Members ist.

Naja, ohne Lesen der Doku gehts nicht. Auch nicht bei PHPs  Zend-Framework (komplett OOP).  Irgendwie scheinen sich die Erklärungen dazu und Argumente alle auch hier zu finden: http://www.yuiblog.com/blog/2010/01/06/inheritance-patterns-in-yui-3/.

Dort wird nur erklärt wie es YUI macht und keiner sagt dass es YUI schlecht macht. Im gegenteil dadurch dass es wenig macht, ist es schnell.

Aber das Problem ist, du kannst mit JS nicht wirklich OO programmieren. Du kannst versuchen einige Muster umzusetzen und du musst hoffen, dass du nichts durcheinander bringst, wenn du mit einem Framework arbeitest das versucht diesen Mangel etwas zu lindern. Aber es fehlen die grundlegendsten Dinge, echte private Member, auf die du z.b. auch in den prototype Funktionen zugreifen kannst und protected geht gar nicht mehr.

Letztlich bleibt der einzige sinnvolle Weg, so wie es Mathias  auch auf seinem Blog beschrieben hat. Private Eigenschaften kennzeichnen, dass sie privat sein sollen und eine einfache Vererbung über die prototype Eigenschaft und den Aufruf der superfunktione über call bzw. apply delegieren.

Bei dem ganzen "gemecker" - das kann aber auch Vorteile bieten.

Die Dynamik der sprache eröffnet prinzipiell auch Möglichkeiten. Dass du z.b. jederzeit, allen bestehenden Instanzen einer Klasse, neue Funktionalität zuweisen kannst, ist in anderen Sprachen deutlich umständlicher.

Auch das ändern von Klassenfunktionen zur Laufzeit kann Vorteile haben.

Und überhaupt für alle Eigenschaften die geändert werden dürfen, Millionen von getter und setter zu schreiben ist mühsam.

Man muss einfach mit dem Arbeiten, was die Sprache kann. Das jemand der u.U. aus der Java Ecke kommt, sich so etwas wie hier vorgestellt wurde, zusammenbaut ist daher nicht verwunderlich. Aber ob es sinnvoll ist bleibt dahin gestellt und muss jeder selber entscheiden ob er die Performanceverluste verkraften kann.

YUI bietet ein pseudoklassisches Inheritance-Pattern mit Y.extend(ChildClass, ParentClass). Einfacher gehts doch nicht, oder?

Eben, mehr gibt es auch nicht.

Struppi.

[jobo]

Hallo,

Aber das Problem ist, du kannst mit JS nicht wirklich OO programmieren.

Naja, ob Soshnikov das auch so sieht. Was soll denn "wirklich OO" sein. Javascript is about Objects. Functions are first class Objects. Das ist dann sprachlich schon verwirrend, wenn ich hier nicht von Objektorientiert sprechen möchte. Objektorientiert heißt meines Verständnisses auch, Objekte abzubilden, also Sinnzusammenhänge zu kapseln. Es heißt auch, dass vererbt werden kann. Ob ich nun "extend" schreibe oder "prototyp" ist doch egal.

Aber es fehlen die grundlegendsten Dinge, echte private Member,

Äh, die sind doch im Funktionsscope geclosed und für innere Funktionen aber weiter verfügbar. Was anderes als das ist das Prinzip von "private"?

auf die du z.b. auch in den prototype Funktionen zugreifen kannst

In PHP ist es doch so, dass private variablen nicht mit vererbt werden.

protected geht gar nicht mehr.

... stattdessen aber protected. Ich kann keine privaten Variablen in Unterfunktionen nutzen so dass sie dann auch vererbbar sind? Das was Crockford priveligierte Funktionen nennt?

Letztlich bleibt der einzige sinnvolle Weg, so wie es Mathias  auch auf seinem Blog beschrieben hat. Private Eigenschaften kennzeichnen, dass sie privat sein sollen und eine einfache Vererbung über die prototype Eigenschaft und den Aufruf der superfunktione über call bzw. apply delegieren.

Naja, das ist ein Weg, um beim programmieren nicht selber durcheinander zu kommen, macht man in Linux ja auch, indem man ein "." voranstellt. "Vorsicht, nicht anpacken". Aber nach außen hin gibt es die Privatheit ja doch, würde ich nach wie vor meinen. Ich sehe diese Konvention mit dem "_" bei YUI aber auch.

  
if (typeof YUI != 'undefined') {  
    YUI._YUI = YUI;  
}  

Gruß

jobo

[Struppi]

Aber das Problem ist, du kannst mit JS nicht wirklich OO programmieren.

Naja, ob Soshnikov das auch so sieht. Was soll denn "wirklich OO" sein. Javascript is about Objects. Functions are first class Objects. Das ist dann sprachlich schon verwirrend, wenn ich hier nicht von Objektorientiert sprechen möchte. Objektorientiert heißt meines Verständnisses auch, Objekte abzubilden, also Sinnzusammenhänge zu kapseln. Es heißt auch, dass vererbt werden kann. Ob ich nun "extend" schreibe oder "prototyp" ist doch egal.

Objekte ist im Prinzip erstmal nichts weiter, als eine Struktur. Das gibt es auch in C. Nur das vorhanden sein eines Objektes macht noch keine OO Sprache. Aber du hast insoweit recht, dass JS einige rudimentäre Mechanismen der OOP mitbringt. Aber sonst nchts.

Aber es fehlen die grundlegendsten Dinge, echte private Member,

Äh, die sind doch im Funktionsscope geclosed und für innere Funktionen aber weiter verfügbar. Was anderes als das ist das Prinzip von "private"?

Ein private Member ist Klassenweit sichtbar, nicht nur im Konstruktor, dass ist genau das, was Florian mit seinem Code erreichen will.

auf die du z.b. auch in den prototype Funktionen zugreifen kannst

In PHP ist es doch so, dass private variablen nicht mit vererbt werden.

Nicht vererbt, ich rede vom prototype der gleichen "Klasse".

protected geht gar nicht mehr.

... stattdessen aber protected. Ich kann keine privaten Variablen in Unterfunktionen nutzen so dass sie dann auch vererbbar sind? Das was Crockford priveligierte Funktionen nennt?

Nein. privilegierte Funktionen dürfen auf private Member zugreifen. Normalerweise heißt aber privilegiert, dass du einer anderen Klasse erlaubst auf die privaten member zu zugreifen.

protected heißt dass du private Elemente vererben kannst. Das geht mit JS Bordmitteln gar nicht.

Letztlich bleibt der einzige sinnvolle Weg, so wie es Mathias  auch auf seinem Blog beschrieben hat. Private Eigenschaften kennzeichnen, dass sie privat sein sollen und eine einfache Vererbung über die prototype Eigenschaft und den Aufruf der superfunktione über call bzw. apply delegieren.

Naja, das ist ein Weg, um beim programmieren nicht selber durcheinander zu kommen, macht man in Linux ja auch, indem man ein "." voranstellt. "Vorsicht, nicht anpacken". Aber nach außen hin gibt es die Privatheit ja doch, würde ich nach wie vor meinen. Ich sehe diese Konvention mit dem "_" bei YUI aber auch.

Eben weil es eben in JS nicht anders geht. Es ist aber nur eine Krücke und letztlich, wie gesagt, die einzige sinnvolle. In Sprachen die OO Regeln umsetzen, brauchst du diese nicht.

Struppi.

[jobo]

Hallo,

Aber das Problem ist, du kannst mit JS nicht wirklich OO programmieren.

Naja, ob Soshnikov das auch so sieht. Was soll denn "wirklich OO" sein. Javascript is about Objects. Functions are first class Objects. Das ist dann sprachlich schon verwirrend, wenn ich hier nicht von Objektorientiert sprechen möchte. Objektorientiert heißt meines Verständnisses auch, Objekte abzubilden, also Sinnzusammenhänge zu kapseln. Es heißt auch, dass vererbt werden kann. Ob ich nun "extend" schreibe oder "prototyp" ist doch egal.

Objekte ist im Prinzip erstmal nichts weiter, als eine Struktur. Das gibt es auch in C. Nur das vorhanden sein eines Objektes macht noch keine OO Sprache. Aber du hast insoweit recht, dass JS einige rudimentäre Mechanismen der OOP mitbringt. Aber sonst nchts.

Naja, würdest Du wenigstens zustimmen, dass Soshnikov das in diesem Kapitel anders sieht? ("ECMAScript is the object-oriented programming language with the prototype based implementation."). Und im folgenden redet er ja von der OOP-Implementation von ECMA-Script. Da ist von rudimentär nicht die Rede,

Aber es fehlen die grundlegendsten Dinge, echte private Member,

Äh, die sind doch im Funktionsscope geclosed und für innere Funktionen aber weiter verfügbar. Was anderes als das ist das Prinzip von "private"?

Ein private Member ist Klassenweit sichtbar, nicht nur im Konstruktor, dass ist genau das, was Florian mit seinem Code erreichen will.

Naja, vielleicht willst du die Variable ja aber auch nur innerhalb einer Funktion sehen und auf den Konstruktor ganz verzichten. So verstehe ich auch peterS.: "mit dem konsequenten verzicht auf konstruktoren fuer eigene objekttypen entfiele in JavaScript auch der irrglaube ueber  >>obj.prototype.constructor<< etwas ueber die natur von >>obj<< zu erfahren<<. sobald mehrfachvererbung ins spiel kommt, hilft auch >>obj instanceof MyConstructor<< nicht weiter." https://forum.selfhtml.org/?t=203423&m=1376347. Und wenn du deinen ganzen Code in einer selbsausführende Funktion packst, bleibt Dein ganzer Klumpatsch doch sowieso nach außen hin komplett privat. Und mir dünkt ja eher, dass man mit Javascript eigentlich viel privater ist als mit "private".

  
myObj = {  
	method1 : function () {  
		var myPrivate = "privat1";  
		return myPrivate;  
	}  
}  
myFunction = function (callback) {  
	alert(callback());  
}  
myFunction(myObj.method1);  

Ich dachte jetzt, Privatheit entsteht, in dem Du Funktionen als Objekte erster Klasse behandelst, was bedeutet, dass Du Privatheit durch callback-Funktionen erzeugst. Die callback-Funktion entscheidet, was passiert. Alles darin ist privat. Die aufrufende Funktion "weiß" nichts über das, was im callback passiert. Wieviel privater solls denn noch sein?

protected geht gar nicht mehr.

Hm, kommt das nicht wirklich darauf an, wo man die Variablen definiert?

  
myObj = {  
	method1 : function () {  
		var myPrivate = "privat1";  
		return myPrivate;  
	}  
}  
myFunction = function (callback) {  
	alert(callback());  
}  
myFunction(myObj.method1);  
  
function object(o) {  
	function F() {}  
	F.prototype = o;  
	return new F();  
}  
var myExtendedObj = object(myObj);  
myFunction(myExtendedObj.method1);  

... stattdessen aber protected. Ich kann keine privaten Variablen in Unterfunktionen nutzen so dass sie dann auch vererbbar sind? Das was Crockford priveligierte Funktionen nennt?

Nein. privilegierte Funktionen dürfen auf private Member zugreifen. Normalerweise heißt aber privilegiert, dass du einer anderen Klasse erlaubst auf die privaten member zu zugreifen.

Und dafür kann ich keine Funktion bauen? U.u. auch eine verschachtelte?

protected heißt dass du private Elemente vererben kannst. Das geht mit JS Bordmitteln gar nicht.

Vielleicht macht es ja auch sinn mal nicht ganz allgemein über Vererbung zu reden sondern ganz konkret. Wieviel Vererbungen machen denn Sinn, und in welchen zusammenhängen?

Letztlich bleibt der einzige sinnvolle Weg, so wie es Mathias  auch auf seinem Blog beschrieben hat. Private Eigenschaften kennzeichnen, dass sie privat sein sollen und eine einfache Vererbung über die prototype Eigenschaft und den Aufruf der superfunktione über call bzw. apply delegieren.

Naja, das ist ein Weg, um beim programmieren nicht selber durcheinander zu kommen, macht man in Linux ja auch, indem man ein "." voranstellt. "Vorsicht, nicht anpacken". Aber nach außen hin gibt es die Privatheit ja doch, würde ich nach wie vor meinen. Ich sehe diese Konvention mit dem "_" bei YUI aber auch.

Eben weil es eben in JS nicht anders geht. Es ist aber nur eine Krücke und letztlich, wie gesagt, die einzige sinnvolle. In Sprachen die OO Regeln umsetzen, brauchst du diese nicht.

Die Frage ist doch eher, wozu dieser Schutz sinnvoll ist. Wenn zB. eh alles in einem Closure gekapselt ist?

Gruß

jobo

[jobo]

Hallo,

Objekte ist im Prinzip erstmal nichts weiter, als eine Struktur. Das gibt es auch in C. Nur das vorhanden sein eines Objektes macht noch keine OO Sprache. Aber du hast insoweit recht, dass JS einige rudimentäre Mechanismen der OOP mitbringt. Aber sonst nchts.

Naja, würdest Du wenigstens zustimmen, dass Soshnikov das in diesem Kapitel anders sieht? ("ECMAScript is the object-oriented programming language with the prototype based implementation."). Und im folgenden redet er ja von der OOP-Implementation von ECMA-Script. Da ist von rudimentär nicht die Rede,

"Objects inherit from objects. What could be more object oriented than that?"

Gruß

jobo

[jobo]

Hallo,

protected geht gar nicht mehr.

Hm, kommt das nicht wirklich darauf an, wo man die Variablen definiert?

myObj = {
method1 : function () {
var myPrivate = "privat1";
return myPrivate;
}
}
myFunction = function (callback) {
alert(callback());
}
myFunction(myObj.method1);

function object(o) {
function F() {}
F.prototype = o;
return new F();
}
var myExtendedObj = object(myObj);
myFunction(myExtendedObj.method1);

>   

Besser so:  
  
~~~javascript
  
myObj = {  
	method1 : function () {  
		var myPrivate = "privat1";  
		return myPrivate;  
	}  
}  
myFunction = function (callback) {  
	alert(callback());  
}  
myFunction(myObj.method1);  
/*  
Crockford 2008-04-07 (http://javascript.crockford.com/prototypal.html):  
"The problem with the object function is that it is global, and globals are clearly problematic.  
The problem with Object.prototype.begetObject is that it trips up incompetent programs,  
and it can produce unexpected results when begetObject is overridden.  
So I now prefer this formulation:"  
*/  
if (typeof Object.create !== 'function') {  
    Object.create = function (o) {  
        function F() {}  
        F.prototype = o;  
        return new F();  
    };  
}  
var myExtendedObj  = Object.create(myObj);  
myFunction(myExtendedObj.method1);  

"For convenience, we can create functions which will call the object function for us, and provide other customizations such as augmenting the new objects with privileged functions. I sometimes call these maker functions. If we have a maker function that calls another maker function instead of calling the object function, then we have a parasitic inheritance pattern.

I have found that by using these tools, coupled with JavaScript's lambdas and object quasi-literals, I can write well-structured programs that are large, complex, and efficient. The classical object model is by far the most popular today, but I think that the prototypal object model is more capable and offers more expressive power.

Learning these new patterns also made me a better classical programmer. Insights from the dynamic world can have application in the static."

Crockford

Gruß

jobo

[Struppi]

Naja, würdest Du wenigstens zustimmen, dass Soshnikov das in diesem Kapitel anders sieht? ("ECMAScript is the object-oriented programming language with the prototype based implementation."). Und im folgenden redet er ja von der OOP-Implementation von ECMA-Script. Da ist von rudimentär nicht die Rede,

Prototype based model of OOP has a number of differences from the static class based paradigm.

Ich befürchte es gibt soviele Schattierungen, in Bezug was OOP bedeutet, dass man letztlich von jeder Sprache behaupten kann sie wäre OO - ich meine ich hätte auch schon die Aussage von Leuten gelesen, dass man auch in C OO schreiben könnte.

Ich finde das Schlüsselwort new() wäre eigentlich schon ein guter Hinweis. Mit new kannst du Instanzen erzeugen. Aber genau die obige Aussage ist das Problem, wenn du eine Vielzahl der Paradigmen, die ein Konzept ausmachen, nicht mehr erfüllen kannst, ist die Frage inweiweit das Konzept umgesetzt ist.

Aber wie schon einmal gesagt, man sollte die Möglichkeiten der Sprache nutzen und nicht irgendwelchen Paradigmen hinterherlaufen, dann klappt's auch mit JS.

Aber es fehlen die grundlegendsten Dinge, echte private Member,

Äh, die sind doch im Funktionsscope geclosed und für innere Funktionen aber weiter verfügbar. Was anderes als das ist das Prinzip von "private"?

private ist in anderen Programmersprachen an die Klasse gebunden. Das was du meinst sind lokale Variabeln.

Ein private Member ist Klassenweit sichtbar, nicht nur im Konstruktor, dass ist genau das, was Florian mit seinem Code erreichen will.

Naja, vielleicht willst du die Variable ja aber auch nur innerhalb einer Funktion sehen und auf den Konstruktor ganz verzichten. So verstehe ich auch peterS.: "mit dem konsequenten verzicht auf konstruktoren fuer eigene objekttypen entfiele in JavaScript auch der irrglaube ueber  >>obj.prototype.constructor<< etwas ueber die natur von >>obj<< zu erfahren<<. sobald mehrfachvererbung ins spiel kommt, hilft auch >>obj instanceof MyConstructor<< nicht weiter." https://forum.selfhtml.org/?t=203423&m=1376347. Und wenn du deinen ganzen Code in einer selbsausführende Funktion packst, bleibt Dein ganzer Klumpatsch doch sowieso nach außen hin komplett privat. Und mir dünkt ja eher, dass man mit Javascript eigentlich viel privater ist als mit "private".

ja, es ist lokal, das Konzept gibt es in anderen Sprachen auch. Aber im Endeffekt drehst und windest du dich, ich weiß natürlich auch, dass man diese Paradigmen umsetzen könnte, sie sind aber einfach kein Bestandteil der Sprache.

Ich dachte jetzt, Privatheit entsteht, in dem Du Funktionen als Objekte erster Klasse behandelst, was bedeutet, dass Du Privatheit durch callback-Funktionen erzeugst. Die callback-Funktion entscheidet, was passiert. Alles darin ist privat. Die aufrufende Funktion "weiß" nichts über das, was im callback passiert. Wieviel privater solls denn noch sein?

Du verwechselst hier was. Nochmal private heißt etwas ist an eine Klasse gebunden und der Zugriff ist nur innherhalb dieser Klasse erlaubt. lokale Variabeln sind lokale Variabeln die im scope einer Funktion (in Javascript) liegen.

protected geht gar nicht mehr.

Hm, kommt das nicht wirklich darauf an, wo man die Variablen definiert?

protected heißt, dass in deinem Beispiel myExtendedObj Zugriff auf die Variabel myPrivate haben müßte, hat sie aber nicht

... stattdessen aber protected. Ich kann keine privaten Variablen in Unterfunktionen nutzen so dass sie dann auch vererbbar sind? Das was Crockford priveligierte Funktionen nennt?

Nein. privilegierte Funktionen dürfen auf private Member zugreifen. Normalerweise heißt aber privilegiert, dass du einer anderen Klasse erlaubst auf die privaten member zu zugreifen.

Und dafür kann ich keine Funktion bauen? U.u. auch eine verschachtelte?

Ich sag doch Krücken gibt es immer, wie Florian schön und elegant, wie ich finde, mit seinem Code gezeigt hat.

protected heißt dass du private Elemente vererben kannst. Das geht mit JS Bordmitteln gar nicht.

Vielleicht macht es ja auch sinn mal nicht ganz allgemein über Vererbung zu reden sondern ganz konkret. Wieviel Vererbungen machen denn Sinn, und in welchen zusammenhängen?

Wenn du OO programmierst überall.

Schon dein Beispielcode könnte einiges mehr an Objekte und Vererbung vertragen, wenn du diesen Konsequent OO umsetzen wollstest.

Naja, das ist ein Weg, um beim programmieren nicht selber durcheinander zu kommen, macht man in Linux ja auch, indem man ein "." voranstellt. "Vorsicht, nicht anpacken". Aber nach außen hin gibt es die Privatheit ja doch, würde ich nach wie vor meinen. Ich sehe diese Konvention mit dem "_" bei YUI aber auch.

Eben weil es eben in JS nicht anders geht. Es ist aber nur eine Krücke und letztlich, wie gesagt, die einzige sinnvolle. In Sprachen die OO Regeln umsetzen, brauchst du diese nicht.

Die Frage ist doch eher, wozu dieser Schutz sinnvoll ist. Wenn zB. eh alles in einem Closure gekapselt ist?

Dann ist es ein closure, mit dem du solche ein Paradigma umsetzt. Oder man benutzt sowas wie Florian uns gezeigt hat. Dort ist das Prinzip wesentlich eleganter umgesetzt und du musst bei deinen Konstruktoren nicht alles Kapseln, sondern kannst diese recht lesbar gestalten. Leider mit den von mir genannnten Nachteilen.

Struppi.

[jobo]

Hallo,

Aber es fehlen die grundlegendsten Dinge, echte private Member,

Äh, die sind doch im Funktionsscope geclosed und für innere Funktionen aber weiter verfügbar. Was anderes als das ist das Prinzip von "private"?

private ist in anderen Programmersprachen an die Klasse gebunden. Das was du meinst sind lokale Variabeln.

das sieht Crockford ua. anders.

Lokale Variablen, die dank Closures im Funktionsscope einer priveligierten Funktion vorhanden sind, sind private Variablen. Denn nur die verschachtelte Funktion kann darauf zugreifen, aber sie kann es immer.

ja, es ist lokal, das Konzept gibt es in anderen Sprachen auch. Aber im Endeffekt drehst und windest du dich, ich weiß natürlich auch, dass man diese Paradigmen umsetzen könnte, sie sind aber einfach kein Bestandteil der Sprache.

Naja, ich verstehe wirklich nicht, was hier nicht umsetzbar ist, außer mit anderer Syntax und einem callback-Konzept.

Du verwechselst hier was. Nochmal private heißt etwas ist an eine Klasse gebunden und der Zugriff ist nur innherhalb dieser Klasse erlaubt. lokale Variabeln sind lokale Variabeln die im scope einer Funktion (in Javascript) liegen.

Naja, s.o.. Die Seite bei Crockford heißt ja "private.html".

protected heißt, dass in deinem Beispiel myExtendedObj Zugriff auf die Variabel myPrivate haben müßte, hat sie aber nicht

Ich sag doch Krücken gibt es immer, wie Florian schön und elegant, wie ich finde, mit seinem Code gezeigt hat.

Was ist das für eine "Krücke", wenn ich in einer Funktion definiere, was privat ist oder nicht bzw. bei der Übergabe einer callbackfunktion. Ich verstehe nur, dass das an anderer Stelle geschieht. Nicht aber, wie ein übergeordnetes Prinzip (Trennung von öffentlichen und privaten(=sicherheitsrelevanten oder den globalen Scope "verschmutzenden")  Variablen) hier nicht umsetzbar sein sollte. Allein die Syntax oder die Logik ist eine etwas andere.

Vielleicht macht es ja auch sinn mal nicht ganz allgemein über Vererbung zu reden sondern ganz konkret. Wieviel Vererbungen machen denn Sinn, und in welchen zusammenhängen?

Wenn du OO programmierst überall.

Naja, eben nicht. Es sei denn, man verwendet OO restriktiv bzw. synonym für "so wie in Java". S.a. das Zitat von Crockford "what can be more objectoriented than that".

Eben weil es eben in JS nicht anders geht. Es ist aber nur eine Krücke und letztlich, wie gesagt, die einzige sinnvolle. In Sprachen die OO Regeln umsetzen, brauchst du diese nicht.

Naja, da beißt sich die Katze in den Schwanz. Macht ja auch nix. Immerhin lässt sich festhalten, dass namhafte und intelligente Menschen den Begriff OO anders fassen (Soshnikov und Crockford wie gesagt).

Dann ist es ein closure, mit dem du solche ein Paradigma umsetzt. Oder man benutzt sowas wie Florian uns gezeigt hat. Dort ist das Prinzip wesentlich eleganter umgesetzt und du musst bei deinen Konstruktoren nicht alles Kapseln, sondern kannst diese recht lesbar gestalten. Leider mit den von mir genannnten Nachteilen.

Also die Lesbarkeit von YUI ist durchaus gegeben, würde ich auf den ersten Blick meinen (Stichwort JSON bzw. quasi-object literal).

Gruß

jobo

[jobo]

Hallo,

protected heißt, dass in deinem Beispiel myExtendedObj Zugriff auf die Variabel myPrivate haben müßte, hat sie aber nicht

Ich sag doch Krücken gibt es immer, wie Florian schön und elegant, wie ich finde, mit seinem Code gezeigt hat.

Was ist das für eine "Krücke", wenn ich in einer Funktion definiere, was privat ist oder nicht bzw. bei der Übergabe einer callbackfunktion. Ich verstehe nur, dass das an anderer Stelle geschieht. Nicht aber, wie ein übergeordnetes Prinzip (Trennung von öffentlichen und privaten(=sicherheitsrelevanten oder den globalen Scope "verschmutzenden")  Variablen) hier nicht umsetzbar sein sollte. Allein die Syntax oder die Logik ist eine etwas andere.

dieser Artikel zu protected beschreibt Dein Argument wohl auch nochmal, dass es protected nicht gibt in Javascript. Aber auch, dass diese übergeordnet eine Sicherheitsfrage und Frage der Codestruktur ist. Ich verstehe es nach wie vor so, dass diese beiden Konzepte (also das übergeordnete Ziel von "protected") mit JS eben anders umzusetzen ist, und nicht über die prototype-chain. Eine andere Variante bzw. Umstetzung von OOP würde ich herauslesen.

Gruß

jobo

[Struppi]

Aber es fehlen die grundlegendsten Dinge, echte private Member,

Äh, die sind doch im Funktionsscope geclosed und für innere Funktionen aber weiter verfügbar. Was anderes als das ist das Prinzip von "private"?

private ist in anderen Programmersprachen an die Klasse gebunden. Das was du meinst sind lokale Variabeln.

das sieht Crockford ua. anders.

Ja, das ist die Umsetzung von JS, aber nicht die Definition.

ja, es ist lokal, das Konzept gibt es in anderen Sprachen auch. Aber im Endeffekt drehst und windest du dich, ich weiß natürlich auch, dass man diese Paradigmen umsetzen könnte, sie sind aber einfach kein Bestandteil der Sprache.

Naja, ich verstehe wirklich nicht, was hier nicht umsetzbar ist, außer mit anderer Syntax und einem callback-Konzept.

Ich sage nicht, dass es nicht umsetzbar ist, aber es ist nicht bestandteil der Sprache. Und wenn du eine private Variabel - also eine Klassengebundene Variabel - definieren willst, musst du Umwege gehen, die wiederrum Fallstricke bergen. Denn wenn du im Konstruktor Funktionen an die Instanz anpappst, überschriebst du den prototypen. Zudem ist es umständlich zur Laufzeit die Funktionen zu definieren. Ausserdem bläht es die Konstruktorfunktion unnötig auf, es ist praktischer und schneller wenn du mit prototypen arbeitest, dann musst du aber auf private Klassenvariabeln verzichten

Du verwechselst hier was. Nochmal private heißt etwas ist an eine Klasse gebunden und der Zugriff ist nur innherhalb dieser Klasse erlaubt. lokale Variabeln sind lokale Variabeln die im scope einer Funktion (in Javascript) liegen.

Naja, s.o.. Die Seite bei Crockford heißt ja "private.html".

http://de.wikipedia.org/wiki/Objektorientierte_Programmierung#Methoden

"Private Methoden können nur von anderen Methoden derselben Klasse aufgerufen werden."

und das ist hier nicht der Fall, nur Funktionen die innerhalb des Konstruktors zur Laufzeit deklariert werden haben Zugriff.

protected heißt, dass in deinem Beispiel myExtendedObj Zugriff auf die Variabel myPrivate haben müßte, hat sie aber nicht

Ich sag doch Krücken gibt es immer, wie Florian schön und elegant, wie ich finde, mit seinem Code gezeigt hat.

Was ist das für eine "Krücke", wenn ich in einer Funktion definiere, was privat ist oder nicht bzw. bei der Übergabe einer callbackfunktion. Ich verstehe nur, dass das an anderer Stelle geschieht. Nicht aber, wie ein übergeordnetes Prinzip (Trennung von öffentlichen und privaten(=sicherheitsrelevanten oder den globalen Scope "verschmutzenden")  Variablen) hier nicht umsetzbar sein sollte. Allein die Syntax oder die Logik ist eine etwas andere.

Genau. Die Logik ist eine andere, darauf wollte ich hinaus.

Vielleicht macht es ja auch sinn mal nicht ganz allgemein über Vererbung zu reden sondern ganz konkret. Wieviel Vererbungen machen denn Sinn, und in welchen zusammenhängen?

Wenn du OO programmierst überall.

Naja, eben nicht. Es sei denn, man verwendet OO restriktiv bzw. synonym für "so wie in Java". S.a. das Zitat von Crockford "what can be more objectoriented than that".

Das ist seine Sichtweise, er betrachtet hier lediglich einen Teilaspekt - die prototypische Vererbung - da mag er Recht haben. Aber es ist eben nur ein Teilaspekt.

Eben weil es eben in JS nicht anders geht. Es ist aber nur eine Krücke und letztlich, wie gesagt, die einzige sinnvolle. In Sprachen die OO Regeln umsetzen, brauchst du diese nicht.

Naja, da beißt sich die Katze in den Schwanz. Macht ja auch nix. Immerhin lässt sich festhalten, dass namhafte und intelligente Menschen den Begriff OO anders fassen (Soshnikov und Crockford wie gesagt).

Keine Ahnung inweit diese als Experten für OOP gelten. Wenn es nur darum geht dass es Objekte gibt und das Verhalten irgendwie simuliert werden kann, dann dürfte jede Sprache ein OO Sprach sein.

Letztlich läßt sich das fehlen mancher Paradigmen nicht leugnen, sondern nur zeigen wie man über Umwege diese trotzdem erfüllt. Und das machen sie  gut.

Dann ist es ein closure, mit dem du solche ein Paradigma umsetzt. Oder man benutzt sowas wie Florian uns gezeigt hat. Dort ist das Prinzip wesentlich eleganter umgesetzt und du musst bei deinen Konstruktoren nicht alles Kapseln, sondern kannst diese recht lesbar gestalten. Leider mit den von mir genannnten Nachteilen.

Also die Lesbarkeit von YUI ist durchaus gegeben, würde ich auf den ersten Blick meinen (Stichwort JSON bzw. quasi-object literal).

Das hatte ich auch bereits gesagt. YUI ist sehr nah an JS und vereinfacht die Vererbung, ansonsten macht es nichts, was nötig wäre.

Struppi.

[jobo]

Hallo,

Fand bei Wikipedias Protypeartikel eigentlich eine gute Zusammenfassung dieser Diskussion (;-):

"Advocates of class-based object models who criticize prototype-based systems often have concerns that could be seen as similar to those concerns that proponents of static type systems for programming languages have of dynamic type systems (see datatype). Usually, such concerns involve: correctness, safety, predictability, efficiency and programmer unfamiliarity.

On the first three points, classes are often seen as analogous to types (in most statically typed object-oriented languages they serve that role) and are proposed to provide contractual guarantees to their instances, and to users of their instances, that they will behave in some given fashion.

Regarding efficiency, declaring classes simplifies many compiler optimizations that allow developing efficient method and instance variable lookup. For the Self language, much development time was spent on developing, compiling, and interpreting techniques to improve the performance of prototype-based systems versus class-based systems. For example, the Lisaac compiler produces code almost as fast as C. Tests have been run with an MPEG-2 codec written in Lisaac, copied from a C version. These show the Lisaac version is 1.9% slower than the C version with 37% fewer lines of code.[5]

A common criticism made against prototype-based languages is that the community of software developers is unfamiliar with them, despite the popularity and market permeation of JavaScript. This knowledge level of prototype-based systems seems to be changing with the proliferation of JavaScript frameworks and increases in the complex use of JavaScript as "Web 2.0" matures."

Gruß

jobo

[jobo]

Hallo,

nochmal (wollte die Überschrift ändern):

Fand bei Wikipedias Protypeartikel eigentlich eine gute Zusammenfassung dieser Diskussion (;-):

"Advocates of class-based object models who criticize prototype-based systems often have concerns that could be seen as similar to those concerns that proponents of static type systems for programming languages have of dynamic type systems (see datatype). Usually, such concerns involve: correctness, safety, predictability, efficiency and programmer unfamiliarity.

On the first three points, classes are often seen as analogous to types (in most statically typed object-oriented languages they serve that role) and are proposed to provide contractual guarantees to their instances, and to users of their instances, that they will behave in some given fashion.

Regarding efficiency, declaring classes simplifies many compiler optimizations that allow developing efficient method and instance variable lookup. For the Self language, much development time was spent on developing, compiling, and interpreting techniques to improve the performance of prototype-based systems versus class-based systems. For example, the Lisaac compiler produces code almost as fast as C. Tests have been run with an MPEG-2 codec written in Lisaac, copied from a C version. These show the Lisaac version is 1.9% slower than the C version with 37% fewer lines of code.[5]

A common criticism made against prototype-based languages is that the community of software developers is unfamiliar with them, despite the popularity and market permeation of JavaScript. This knowledge level of prototype-based systems seems to be changing with the proliferation of JavaScript frameworks and increases in the complex use of JavaScript as "Web 2.0" matures."

Gruß

jobo

[Struppi]

Fand bei Wikipedias Protypeartikel eigentlich eine gute Zusammenfassung dieser Diskussion (;-):

Naja.

"Advocates of class-based object models who criticize prototype-based systems ..

Ich weiß nicht ob es euch aufgefallen ist, ich kritisiere das prototype System nicht. Ich arbeite damit ja lange genug und ich finde Javascript Toll.

Ich sag nur wie es ist. Es ist Fakt, dass JS ein anderes Konzept hat und dass es manche OOP Paradigmen gibt, die nur über Umwege umgesetzt werden können. Das  aufgrund der extremen Dynamik der Sprache, das Programmieren manchmal eine große Dispziplin erfordert. Ich hab oft genug schon dagegessen und stundelang irgendwelche Objekte gesucht, die auf unerklärliche Weise nicht mehr verfügbar waren oder irgendwo anders her kamen. Das ist auch eine der in Foren am häufigsten gestellten Fragen, "warum ist mein this nicht mehr die Instanz meines Objektes?"

Auch ich habe deshalb schon Tage damit verbracht, mir für diese Schwierigkeiten Hilfen zu bauen, ein Framework oder Helper Objekte. Und letztlich erkannt, dass, wie so oft, weniger mehr ist.

Trotzdem ist bleibt es schwierig und nicht umsonst gibt es in YUI, Mootools, protptye, usw. überall diese Funktionen um dem JS Programmierer zu helfen. Und solange du nicht sicher bist, welches das Beste ist, ist es nervig, da alle andere Wege anbieten. Es wäre schöner, wenn es einen Weg gäbe, den die Sprache an sich hätte und wie es aussieht sind diese Dinge auf dem Weg (werden aber vermutlich 10 Jahre brauchen, bis sie allgemein eingesetzt werden können).

Wenn ob man JS wirklich eine OO Sprache nennen will, dann müßten solche Sachen wie Class, private, protected und einen Klassenweite scope geben und nicht die Aussage, dann muss man sich eben mit anderen Techniken helfen oder dieses oder jenes pattern ist aber eleganter. Denn wie gesagt, solche Muster lassen sich mit so gut wie jeder Sprache umsetzen und Objekte oder Strukturen gibt es auch fast überall, das würde dann letztlich bedeuten jede Sprache ist eine OO Sprache. Was aber am Kern vorbei geht. Die Frage dabei ist, was bietet dir die Sprache an?

Denn im Prinzip stimmt es auch, du kannst mit jeder Sprache OO programmieren. Aber ob man JS, mit seinem zwei dafür zu Verfügung gestellten Eigenschaften 'new' und 'prototype', als OOP Sprache bezeichnen kann, halte ich zumindest für überzogen. Sie hilft dir ein bisschen dabei, aber für die Umsetzung der Konzepte, bist du verantwortlich und musst dich - zumindest momentan noch -selber drum kümmern.

Genau darum geht es in diesem Thread. Ausgangspunkt der Diskussion, war eine Bibliothek, die versucht hat die Konzepte zu erweitern, wenn JS diese hätte wäre sowas nicht nötig. Ihr sagt solche Bibliotheken sind überflüssig, was seltsam ist, denn YUI, Mootools usw. bieten genau das auch an. Also kann es nicht überflüssig sein und es scheint also notwendig zu sein JS damit auf die Sprünge zu helfen.

Und ich stimme da Mathias auch völlig zu, für diese Hilfe benötigt es vor allem einen anderen Ansatz, als in anderen Sprachen wie z.b. Java, der sich mit wenigen Funktionen umsetzen läßt und nicht alle OOP Paradigmen 100% erfüllt. Dann kann man auch in JS OO programmieren.

Struppi.

[molily]

Trotzdem ist bleibt es schwierig und nicht umsonst gibt es in YUI, Mootools, protptye, usw. überall diese Funktionen um dem JS Programmierer zu helfen. Und solange du nicht sicher bist, welches das Beste ist, ist es nervig, da alle andere Wege anbieten. Es wäre schöner, wenn es einen Weg gäbe, den die Sprache an sich hätte und wie es aussieht sind diese Dinge auf dem Weg (werden aber vermutlich 10 Jahre brauchen, bis sie allgemein eingesetzt werden können).

Wieso gibt es hunderttausende PHP-Frameworks? Wieso entstehen ständig neue obskure Nischen-Programmiersprachen? Wieso ist Rails Ruby, aber besteht aus mehreren weiteren Domain-Specific Languages? Wieso ist PHP total out, wieso interessieren sich alle plötzlich für Node.JS, wieso für CoffeeScript? Wieso ändert ein Framework von einer Version zur anderen plötzlich seine gesamte API? Wieso will PrototypeJS in der kommenden Version keine Natives mehr erweitern?

Weil: There's more than one way to do it. Es gibt tausend Wege, ein Problem zu lösen, und zehn davon sind wahrscheinlich richtig gut. Und kurze Zeit später kommt jemand mit einer ganz neuen Idee um die Ecke und zeigt auf, dass die alte problematisch ist. Das ist Vielfalt und Fortschritt, ganz normal.

JavaScript hat einen Weg »an sich«. Er lautet: Mutable Objects, einfache Object-Notation, Funktionen als First-Class Objects, Closures, funktionaler Scope, prototypische Delegation. Das ist JavaScript seit dem ersten Tag und das wird es voraussichtlich bleiben.

Dieser Weg wird recht konsequent in ES5 verfeinert: einfachere Delegation, Function Binding, funktionale Listenoperationen, die Zugriffsrechte enumerable/configurable/writable, preventExtensions, Sealing und Freezing, Getter und Setter, Strict Mode.

Und weiter in Harmony: Block Scope, Konstanten, Default-Parameter, »Rest«-Parameter statt »arguments«, Destructuring, lexikalisches this usw.

Wird das alles zehn Jahre dauern? Sicher nicht. ECMAScript ist seit einem Jahr draußen und wird schon recht breit unterstützt. Das können noch nicht alle Browser? Richtig, aber das Problem haben wir jederzeit mit sämtlichen Webtechniken. Siehe HTML5 und CSS3.

Wenn ob man JS wirklich eine OO Sprache nennen will, dann müßten solche Sachen wie Class, private, protected und einen Klassenweite scope geben

Ich bin kein Informatiker, aber bei allem, was ich weiß, ist das falsch. OO definiert sich nicht notwendig über Klassen. Klassen sind eine mögliche Umsetzung von OOP-Konzepten, die m.W. nicht am Anfang von OOP stand.

Denn im Prinzip stimmt es auch, du kannst mit jeder Sprache OO programmieren. Aber ob man JS, mit seinem zwei dafür zu Verfügung gestellten Eigenschaften 'new' und 'prototype', als OOP Sprache bezeichnen kann, halte ich zumindest für überzogen.

Ich würde sie nicht WEGEN sondern TROTZ dieser beiden Eigenschaften als OO bezeichnen.

Genau darum geht es in diesem Thread. Ausgangspunkt der Diskussion, war eine Bibliothek, die versucht hat die Konzepte zu erweitern, wenn JS diese hätte wäre sowas nicht nötig.

JavaScript hat keine Klassen - ist es schon aus diesem Grund heraus nötig, sie nachzubauen? Mit Sicherheit nicht. Klassen sind nicht das Ziel, sondern bloß ein möglicher Weg. Brauchen JavaScript-Programmierer zudem eine Kapselung in genau dieser Form? Das bezweifle ich stark. Ist diese Umsetzung sauber? Sie ist clever, aber gemäß gängigen JavaScript-Konventionen ein Albtraum.

Ihr sagt solche Bibliotheken sind überflüssig,

Ich weiß nicht, wen du mit »ihr« meinst und ich wüsste nicht, wer das in diesem Thread gesagt haben soll. Hingegen wurden viele gute Einwände und Schwierigkeiten geäußert.

was seltsam ist, denn YUI, Mootools usw. bieten genau das auch an. Also kann es nicht überflüssig sein und es scheint also notwendig zu sein JS damit auf die Sprünge zu helfen.

JavaScript hat auch ohne Vererbung mit Klassen sowie Member-Zugriffsrechte (protected/private) genug, um auf die Sprünge zu kommen.

Die genannten Bibliotheken bieten zwei Dinge:

1. Komfort und Einfachheit - das ist notwendig, wenn der Code umfangreicher und komplexer wird,
2. feste Strukturen und Konventionen - auch diese sind notwendig, aber INHALTLICH UNBESTIMMT, also durch die Wahl der Bibliothek bestimmbar.

Und ich stimme da Mathias auch völlig zu, für diese Hilfe benötigt es vor allem einen anderen Ansatz, als in anderen Sprachen wie z.b. Java, der sich mit wenigen Funktionen umsetzen läßt und nicht alle OOP Paradigmen 100% erfüllt. Dann kann man auch in JS OO programmieren.

Es gibt es doch kein grundlegendes Problem damit, komplexere Bibliotheken einzusetzen, die weitere OOP-Konzepte in JS einführen, wenn man dadurch besser programmieren kann. Sei es nun Joose, JS.Class oder class.js. Was sollte dagegen sprechen? Dass es Komplexität hinzufügt? Das gilt für sämtliche Software, die man im Web verwendet: MySQL, CouchDB, Redis. Zend Framework, Django, Ruby on Rails. Joomla, Drupal, TYPO3. Qooxdoo, Ext JS, Dojo. Flash, Flex, Papervision3D. Alles nicht einfach, aber teilweise sinnvoll und nötig.

Wer sagt denn, dass das in JavaScript nicht sein soll? Weil es die Performance bremst? Das tut es, aber immer weniger und weniger. Wenn ich heute auf ein JS-Projekt schaue, was ich vor einem Jahr low-level entwickelt habe, muss ich lachen, was für absurde Performance-Optimierungen ich vornehmen musste. Mit etwas neueren Browsern haben sich die Schwierigkeiten von selbst gelöst. Gut, damals habe ich halt auf etwas Komfort verzichtet, das war für mich kein großes Problem. Anfangen hatte ich da aber mit JS.Class.

Mathias

[jobo]

Hallo Mathias,

Wieso ist PHP total out, wieso interessieren sich alle plötzlich für Node.JS, wieso für CoffeeScript?

Echt. PHP ist out? Node.js (=serverseitiges Javascript) finde ich macht ja theoretisch am meisten Sinn (und ich fragte mich schon seit Jahren, warum man kein serverseitiges JS einsetzt bzw. das nicht populär ist oder wird). Wenn ich dem Client per Javascript "anbiete", JSON-Objekte in den DOM-Baum einzuflechten, dann bleibt ja, so wie ich das verstehe, immer noch der Fallback zur Serverseite in der Regel nötig, falls der Client JS nicht kann oder will. Da muss ich dann bei meinem kleinen Experimentierprojekt eben auf dem Server nochmal das nachbauen, was ich für den Client mit JS grade gemacht habe. Macht natürlich viel mehr Sinn, wenn ich das JS auch zum Ausliefern von nur-HTML auch auf dem Server laufen lassen kann. Brauch ich keine Übersetzung nach PHP (;-). Oder?

Ansonsten Danke für die Zusammenfassungen!!! Mich dünkt, mittlerweile ist (von Dir) so ziemlich alles dazu gesagt und verlinkt.

Gruß

jobo

[Struppi]

Echt. PHP ist out? Node.js (=serverseitiges Javascript) finde ich macht ja theoretisch am meisten Sinn (und ich fragte mich schon seit Jahren, warum man kein serverseitiges JS einsetzt bzw. das nicht populär ist oder wird). Wenn ich dem Client per Javascript "anbiete", JSON-Objekte in den DOM-Baum einzuflechten, dann bleibt ja, so wie ich das verstehe, immer noch der Fallback zur Serverseite in der Regel nötig, falls der Client JS nicht kann oder will.

Du darfst  nicht vergessen, dass du so oder so immer http dazwischen hast. D.h. du hast im Grunde keinen besonderen Vorteil, dass du JS auf dem Server hast. Es ist halt einfach noch eine andere CGI Programmiersprache, du hast aber dadurch kein DOM auf dem Server.

Ansonsten Danke für die Zusammenfassungen!!! Mich dünkt, mittlerweile ist (von Dir) so ziemlich alles dazu gesagt und verlinkt.

Mich dünkt, dass wir auch irgendwie an einander vorbei reden, es gibt im Grund in diesem Thread nur einen Punkt um den es (mir) ging.

Struppi.

[jobo]

Hallo Struppi,

Echt. PHP ist out? Node.js (=serverseitiges Javascript) finde ich macht ja theoretisch am meisten Sinn (und ich fragte mich schon seit Jahren, warum man kein serverseitiges JS einsetzt bzw. das nicht populär ist oder wird). Wenn ich dem Client per Javascript "anbiete", JSON-Objekte in den DOM-Baum einzuflechten, dann bleibt ja, so wie ich das verstehe, immer noch der Fallback zur Serverseite in der Regel nötig, falls der Client JS nicht kann oder will.

Du darfst  nicht vergessen, dass du so oder so immer http dazwischen hast. D.h. du hast im Grunde keinen besonderen Vorteil, dass du JS auf dem Server hast. Es ist halt einfach noch eine andere CGI Programmiersprache, du hast aber dadurch kein DOM auf dem Server.

Aber man braucht die Dombefehle nur einmal zu programmieren. Es geht ja eher um die Fähigkeit, quasi als Abfallprodukt, das als Textfile auszugeben.

Ansonsten Danke für die Zusammenfassungen!!! Mich dünkt, mittlerweile ist (von Dir) so ziemlich alles dazu gesagt und verlinkt.

Mich dünkt, dass wir auch irgendwie an einander vorbei reden, es gibt im Grund in diesem Thread nur einen Punkt um den es (mir) ging.

Deshalb hab ich da gleich nochwas dazugeschrieben. Nicht dass wir hier unerlaubtes Thread-Crossovering betreiben (;-).

Gruß

jobo

[Struppi]

Du darfst  nicht vergessen, dass du so oder so immer http dazwischen hast. D.h. du hast im Grunde keinen besonderen Vorteil, dass du JS auf dem Server hast. Es ist halt einfach noch eine andere CGI Programmiersprache, du hast aber dadurch kein DOM auf dem Server.

Aber man braucht die Dombefehle nur einmal zu programmieren. Es geht ja eher um die Fähigkeit, quasi als Abfallprodukt, das als Textfile auszugeben.

Ich kenne mich mit node.js nicht aus, aber ich bezweifle, dass du bezüglich des DOM irgendeinen nutzen davon hast. Es ist eine Serverseitige Sprache.

Wie Mathias schon andeutete, der Vorteil oder die Stärken, liegen in anderen Bereichen.

Deshalb hab ich da gleich nochwas dazugeschrieben. Nicht dass wir hier unerlaubtes Thread-Crossovering betreiben (;-).

Ich glaub nicht, dass den thread ausser uns noch jemand liest ;-)

Struppi.

[jobo]

Hallo,

Ich kenne mich mit node.js nicht aus, aber ich bezweifle, dass du bezüglich des DOM irgendeinen nutzen davon hast. Es ist eine Serverseitige Sprache.

Hatte da mal so einen Vortrag online gesehen... (;-)

Wie Mathias schon andeutete, der Vorteil oder die Stärken, liegen in anderen Bereichen.

Deshalb hab ich da gleich nochwas dazugeschrieben. Nicht dass wir hier unerlaubtes Thread-Crossovering betreiben (;-).

Ich glaub nicht, dass den thread ausser uns noch jemand liest ;-)

Naja, das Thema ist nicht durch. Denn so wie ich das sehe gehen da Teile der "good Parts" von Javascript da mit rein und Programmierer, die bisher nur ein Vererbungssystem kennengelernt haben setzen sich mit einem für sie neuen anderen auseinander. Insofern könnte es ja vielleicht hie und da mal auch Verweise ins Archiv auf diese Diskussion geben. Da sind ja auch einige interessante Links gesammelt jetzt.

Gruß

jobo

[jobo]

Hallo,

Du darfst  nicht vergessen, dass du so oder so immer http dazwischen hast. D.h. du hast im Grunde keinen besonderen Vorteil, dass du JS auf dem Server hast. Es ist halt einfach noch eine andere CGI Programmiersprache, du hast aber dadurch kein DOM auf dem Server.

Aber man braucht die Dombefehle nur einmal zu programmieren. Es geht ja eher um die Fähigkeit, quasi als Abfallprodukt, das als Textfile auszugeben.

Ich kenne mich mit node.js nicht aus, aber ich bezweifle, dass du bezüglich des DOM irgendeinen nutzen davon hast. Es ist eine Serverseitige Sprache.

"There are a lot of advantages that come from it. One is that you can run the same stuff on both sides of the network. We can take YUI – the same YUI that you're running in the browser – and run it in the server. That means your applications can run on either side. Maybe you want to do the initial page load on the server side so you can send HTML over the first view, so views are going to be looking at that while you're sending the rest of the scripts over. You can do that now trivially. It used to be you had to write the program twice in order to have the two views, but now you only have to do that once. If you wanted to have a web service which provides a portion of that view so that it can be included in other programs, that web service can be created with the same program. " Crockford u.a. über node.js

Gruß

jobo

[peterS.]

gruss Jobo,

"There are a lot of advantages that come from it. ...
... umfangreiches zitat ...
... If you wanted to have a web service which provides a portion of that
view so that it can be included in other programs, that web service can
be created with the same program."
Crockford u.a. über node.js

da redet Crockford aber garantiert nicht ueber die grundlagen von node.js

Im Zitat wird nur aufgezeigt was mit nativem JavaScript auf beiden
Seiten, Server und Client, möglich ist. da braucht es nicht unbedingt
node.js dazu

der grundgedanke von node.js ist "non blocking IO" - no less, no more.

so long - peterS. - [e-mail]

[peterS.]

huhu,

Ich glaub nicht, dass den thread ausser uns noch jemand liest ;-)

doch ich - ich lese seit jahren wirklich fast alle »(JavaScript)« posts
von ... trommelwirbel ... »Struppi« und »molily«.

meist habt Ihr einem fragesteller aber so schnell bzw. so umfassend
geantwortet, dass ich dann nicht auch noch meinen senf dazugeben muss.

gruesse - peterS. - [e-mail]

[JürgenB]

Hallo peterS.,

doch ich - ich lese seit jahren wirklich fast alle »(JavaScript)« posts
von ... trommelwirbel ... »Struppi« und »molily«.

ach, du auch?

Gruß, Jürgen

PS Nur fürs Protokoll: Ich lese auch noch mit.

[molily]

PHP ist out?

Bei Hackern und Enthusiasten, ja. Natürlich ist die PHP-Industrie noch tausendmal größer. Manche hier können ein Lied davon singen, wie es ist, so etwas wie Closures in PHP einzubauen. ;)

Node.js (=serverseitiges Javascript) finde ich macht ja theoretisch am meisten Sinn (und ich fragte mich schon seit Jahren, warum man kein serverseitiges JS einsetzt bzw. das nicht populär ist oder wird).

Serverseitiges JS gab es schon vorher und auch recht stabil. Das Neue an NodeJS ist asynchronones I/O und der Event Loop. Aus JavaScript-Sicht nichts Neues, aus Sicht von serverseitigen Webanwendungen schon (gut, Ruby hat EventMachine und Python Twisted, bei NodeJS wird es zum Prinzip erhoben).

Mathias

[jobo]

Hallo,

PHP ist out?

Bei Hackern und Enthusiasten, ja. Natürlich ist die PHP-Industrie noch tausendmal größer. Manche hier können ein Lied davon singen, wie es ist, so etwas wie Closures in PHP einzubauen. ;)

Naja, wieso nicht?

Node.js (=serverseitiges Javascript) finde ich macht ja theoretisch am meisten Sinn (und ich fragte mich schon seit Jahren, warum man kein serverseitiges JS einsetzt bzw. das nicht populär ist oder wird).

Serverseitiges JS gab es schon vorher und auch recht stabil. Das Neue an NodeJS ist asynchronones I/O und der Event Loop.

Den Beitrag habe ich mir schon mal angeschaut (habs an Grace Hopper erkannt) und wohl nicht viel behalten (=verstanden) davon (;-). Guter Hinweis, pack ich mir auf meinen Termin-Stack (;-).

Aus JavaScript-Sicht nichts Neues, aus Sicht von serverseitigen Webanwendungen schon (gut, Ruby hat EventMachine und Python Twisted, bei NodeJS wird es zum Prinzip erhoben).

Ja, das sagt ja Crockford schon zu Beginn, dass er das für etwas Grundlegenderes hält.

Gruß

jobo

[molily]

Aber das Problem ist, du kannst mit JS nicht wirklich OO programmieren. Du kannst versuchen einige Muster umzusetzen und du musst hoffen, dass du nichts durcheinander bringst, wenn du mit einem Framework arbeitest das versucht diesen Mangel etwas zu lindern. Aber es fehlen die grundlegendsten Dinge, echte private Member, auf die du z.b. auch in den prototype Funktionen zugreifen kannst und protected geht gar nicht mehr.

Peter hat zu der Frage ja eigentlich alles schon gesagt, die Soshnikov-Artikel wurden auch schon verlinkt. Dennoch will ich noch etwas einwerfen.

OOP heißt für mich erst einmal, dass es Objekte als Gruppierungen von Daten und Funktionalität gibt und diese Objekte einander Nachrichten senden: »Alan Kay coined the phrase Object-Oriented Programming, but this is not his fault. He has repeatedly said that to him, OOP is about encapsulation and message passing, not inheritance and ontologies of types.« (Quelle) Weitere OOP-Konzepte bauen darauf auf. Das alles macht man nicht zum Selbstzweck, sondern weil man sich davon Vorteile entspricht.

Zu dem wichtigsten gehört wohl die Kapselung bzw. das Information Hiding. Das ist, wie Soshnikov erklärt, erst einmal eine Technik zur Verbesserung der Datenstrukturierung vom Programmierer für den Programmierer. Er zeigt das anschaulich daran, dass die Sprachen Python und Ruby zwar public/protected/private unterscheiden, aber dies nicht mehr als eine Metainformation ist. Mit Tricks ist der Zugriff trotzdem möglich. Das ist kein Widerspruch zum Kapselungskonzept. Offenbar gilt ähnliches auch für andere Sprachen, Wikipedia schreibt: »Almost always there is a way to override such protection«, auch in C++ und Java.

Die Unterscheidung zwischen public und private soll also erst einmal mein Denken, meine Strukturierung des Programms, mein Design des Objekt-Messagings verbessern, indem ich klar definiere, auf was für Nachrichten das Objekt nach außen reagier, welche Daten es geordnet herausgibt und welche es für sich behält. Alles andere sind Interna, die ich wiederum ordentlich zu strukturieren habe. Dabei hilft mir OOP nur bedingt weiter.

Eine zweite große OOP-Idee ist, dass Funktionalität von Objekten wiederverwendet wird. Dass das nötig und nützlich ist, liegt auf der Hand. Dazu gibt es, soweit ich das verstehe, zwei (sich nicht ausschließende) Richtungen, die der Composition mit Traits, Mixins und Hat-Beziehungen sowie die der Delegation und der Vererbung. Abstrakte Typen wie Klassen und Interfaces sind eine andere Ebene und bauen auf den genannten Ansätzen auf. (So erkläre ich mir das - denn es lässt sich ja selbst bei prototypischer Delegation ein »abstraktes« Objekt erzeugen, das selbst nur als Prototyp dient.)

Es gibt also ein breites Feld von OOP-Konzepten für Code Reuse. Manche davon sind bereits in JavaScript eingebaut, andere lassen sich problemlos mit JavaScript-Mitteln umsetzen. Was hingegen schwierig ist und immer schwierig sein wird, ist eine gewisse OOP-Umsetzung möglichst getreu zu kopieren. Der plausible Beweggrund dafür kann nur der sein, dass man Kenner dieser OOP-Umsetzung gewinnen will. Dahinter kann noch der Grund stehen, die Disziplin und den Zwang einer strengen, statischen Sprache auf JavaScript zu übertragen.

Die Idee ist an sich nicht schlecht. Aus solchen Überlegungen entstanden CoffeeScript, aber auch Objective-J und der Google Web Toolkit. PrototypeJS hat beispielsweise viele Ideen von Ruby und Ruby on Rails geerbt. Das alles funktioniert hervorragend, solange Maßstab nicht lautet: Wie exakt kann ich Java-Klassen in JS umsetzen? Sondern: Welche (bekannten, gerne entlehnten) OOP-Konzepte helfen mir, meine Probleme strukturiert in Code auszudrücken? Welche OOP-Konzepte passen zu JS und wie setze ich sie um?

Da kann natürlich auch so etwas radikales wie Objective-J oder GWT herauskommen, wo JavaScript nur noch die Sprache ist, in die kompiliert wird. Der Mainstream geht jedoch – meiner Ansicht nach aus guten Gründen – eher dahin, bei JavaScript die »Good Parts« nicht zu überdecken und die Expressivität nicht einzuschränken, sondern die wirklichen Anwendungsprobleme (Native Objects, der Browser, das DOM, fortgeschrittenes OOP) zu vereinfachen.

Das hat sicher Vor- und Nachteile. jQuery beispielsweise bietet einem recht wenig Halt, weil es keine umfassendere Philosophie wie etwa PrototypeJS hat. Man kann totalen Spaghetticode in jQuery schreiben, aber auch sehr gut strukturierten und dabei von vielen abstrakten jQuery-Konzepten Gebrauch machen. jQuery ist vielleicht auch deshalb so erfolgreich, weil es einerseits eine recht einheitliche, funktionale API für DOM-Operationen und Event-Handling hat, aber keine Grobstrukturierung erzwingt. Das heißt, dass Einsteiger ohne JavaScript-Hintergrundwissen damit erst einmal Spaghetticode schreiben werden. Fortgeschrittenen obliegt es, Object-Literale, Revealing Modules, prototypische Delegation, Pseudoklassen, komplexere OOP-Bibliotheken usw. einzusetzen.

Mathias

[Struppi]

OOP heißt für mich erst einmal, dass es Objekte als Gruppierungen von Daten und Funktionalität gibt und diese Objekte einander Nachrichten senden: »Alan Kay coined the phrase Object-Oriented Programming, but this is not his fault. He has repeatedly said that to him, OOP is about encapsulation and message passing, not inheritance and ontologies of types.« (Quelle)

und genau das ist das Problem von JS. Die Kapselung erfolgt nicht so, dass sie für einen OO Ansatz wirklich verwendbar ist.

Das geht nicht:

function MyClass(){  
var private;  
}  
  
MyClass.prototype.myFunction = function() {  
alert(private);  
};  

Und damit ist die Kapselung hinfällig oder du musst den Umweg über ein zusätzliches closure gehen.

Darum ging es in der vorgestellten Bibliothek von Florian und darum ging es mir in der Diskussion.

Ich kritisiere das Konzept gar nicht, ich bin es nicht anders gewohnt. Meine Versuche in Java oder C++ liegen lange zurück und seit dem programmiere ich mit Sprachen die das OOP konzept nicht so streng umsetzen.

Da ich anfangs ebenfalls Schwierigkeiten beim umsetzen von OO in JS hatte, weil eben (für mich) überraschend der prototype verschwunden ist oder die privaten Variabeln in allen Objekten gleich waren (weil es in JS keine Meldung gibt, wenn man den Superkonstruktor einer abgeleiteten Klasse nicht aufruft), kann ich nachvollziehen warum jemand versucht diese Hürden aus den Weg zu räumen.

Die Konzepte der gängigen Frameworks machen das nicht, da sie auf die Erfahrung beruhen, dass die Wege um eine konsequentere Kapselung zu erreichen, immer Rechenzeit fressen. Aber deshalb kann ist aus meiner Sicht die Intention von Florian völlig klar gewesen.

Struppi.

[jobo]

Hallo,

und genau das ist das Problem von JS. Die Kapselung erfolgt nicht so, dass sie für einen OO Ansatz wirklich verwendbar ist.

Das geht nicht:

function MyClass(){

var private;
}

MyClass.prototype.myFunction = function() {
alert(private);
};

  
~~~javascript
  
function MyClass(){  
	var myPrivate = "privat";  
	this.getMyPrivate = function () {  
		alert(myPrivate);  
	}  
}  
var myObj = new MyClass();  
alert(myObj.myPrivate); // undefined  
myObj.getMyPrivate(); // "privat"  
MyClass.prototype.myFunction = function() {  
	alert("gibsnich: " + typeof myPrivate);  
};  
alert(myObj.myFunction);  
myObj.myFunction(); //myPrivate is undefined  

Schien bei mir so zu funktionieren. "Private" ist reserviert.

Und damit ist die Kapselung hinfällig oder du musst den Umweg über ein zusätzliches closure gehen.

Wieso ist ein Closure ein Umweg?

Gruß

jobo

[Struppi]

function MyClass(){
var myPrivate = "privat";
this.getMyPrivate = function () {
alert(myPrivate);
}
}

Damit wird bei jedem erzeugen einer Instanz, jedesmal auf's neue, eine Funktion erzeugt und an die aktuelle Instanz angepappt. Das musst du für jede Funktion machen, die auf myPrivate zugreifen können muss. Kurz gesagt, du verzichtest auf eine der Sprachmerkmale, weil du hier nicht mehr prototype verwenden kannst, damit du etwas erreichst, was der Sprache fehlt.

Und ich weiß nicht, ob dir klar ist, dass ich diese Möglichkeiten kenne?
Mir ging es darum zu zeigen was in JS nicht geht und nicht wie es möglich wäre ein ähnliches Verhalten zu simulieren.

Und damit ist die Kapselung hinfällig oder du musst den Umweg über ein zusätzliches closure gehen.

Wieso ist ein Closure ein Umweg?

Weil du es nicht so schreiben kannst, wie ich es in meinem Beispiel gezeigt habe.

Struppi.

[molily]

Die Kapselung erfolgt nicht so, dass sie für einen OO Ansatz wirklich verwendbar ist.

Die Fähigkeiten von JavaScript sind in dem Punkt nicht miteinander verknüpft.

Konstruktoren und deren prototype-Eigenschaften sind ein gesondertes Ding, das sich nicht in die Sprache einfügt. Dass sie keine Private Members einführen, halte ich eigentlich noch für stimmig. Das wäre ja plötzlich »Magie«, während alles andere sich mit der Property Lookups, Prototype Chain, der Scope Chain usw. erklären lässt.

Funktionen hängen ja nur lose an Objekten und sie nicht an sie gebunden. Daher wäre es erst einmal unlogisch, ihnen besondere Rechte beim Zugriff auf andere Objektmember zu geben. Ihre Beziehung zum Objekt ist keine besondere, höchstens in dem Sinne, dass ihr die Hat-Beziehung durch »this« mitgeteilt wird, wenn sie über diesen Pfad aufgerufen wird.

Dass JavaScript hier Features hat, die nicht widerspruchslos miteinander kombinierbar sind, ist bekannt. Es kommt nicht von ungefähr, dass Crockford das Konstruktor-Prototyp-Pattern als irreführend verurteilt. Das ist es tatsächlich. Es referiert auf klassenbasierte OOP, löst diese aber nicht ein, weil JS nur einfache Objekte und First-Class-Funktionen kennt. Es ist weder wirklich funktional (was Kapselung durch Funktionsscops und Closures erlauben würde) noch wirklich prototypisch (was einfache Delegation erlauben würde).

Darum ging es in der vorgestellten Bibliothek von Florian und darum ging es mir in der Diskussion.

Die Idee, beides zusammenzubringen, halte ich ja nicht für falsch. Wie gesagt, das ist absolut nichts neues. Die einen gehen den Weg, dass sie Konstruktoren/prototype-Eigenschaften gar nicht mehr verwenden und direkt auf funktionale/prototypische OOP setzen. Mootools geht den Weg, dass sich Methoden mit dem $protected-Flag versehen lassen (function () {}.protect()). Da Mootools wie gesagt sowieso jeden Methodenaufruf kapselt, prüfen sie bei der Gelegenheit einfach auch den $protected-Flag (siehe Mootools' Class.js). Wenn ich das richtig sehe, müsste es genauso möglich sein, sämtliche Methoden mit _-Präfix automatisch protected zu machen.

Das sind alles »behutsamere« Methoden, wo ich mich frage, ob das nicht schon völlig ausreicht. Mootools Implementierung ist unter dem Strich sehr kompakt und einfach.

Ich kritisiere das Konzept gar nicht, ich bin es nicht anders gewohnt.

Es ist aber kritikwürdig und selbst die Gurus verteufeln es. ;)

Mathias

[molily]

Noch ein anderes Beispiel in ES5:

function makeO () {  
	var o = {};  
	Object.defineProperties(o, {  
		öffentlicheMethode : {  
			value : function () { this._privateMethode(); },  
			enumerable : true, writable : false, configurable : false  
		},  
		_privateMethode : {  
			value : function () { alert('Hallo Welt'); },  
			enumerable : false, writable : false, configurable : false  
		},  
		öffentlicheEigenschaft : {  
			get : function () { return this._privateEigenschaft * 5; },  
			set : function (v) { this._privateEigenschaft = v / 5; },  
			enumerable : true, configurable : false  
		},  
		_privateEigenschaft : {  
			value : 1,  
			enumerable : false, writable : true, configurable : false  
		}  
	});  
	Object.preventExtensions(o);  
	return o;  
}  
  
var o1 = makeO();  
o1.öffentlicheMethode();  
alert(o1.öffentlicheEigenschaft);  
o1.öffentlicheEigenschaft = 100;  
alert(o1.öffentlicheEigenschaft);

Das ist jetzt natürlich eine sehr verquaste Schreibweise. Den ganzen Kladderadatsch könnte man aber wunderbar wegabstrahieren.

Natürlich habe ich hier keine effektive Kapselung. _privateEigenschaft ist immer noch ein normaler Member, den ich von außen lesen und schreiben kann. Aber wieso brauche ich noch mehr? Wobei hilft mir das? Bei YUI gibt es tausende pseudo-protected Methoden. Wem schadet das? Ist das für Modulautoren unklar? Es ist doch recht simpel. Protected Methoden werden mit _-Präfix versehen und mit JSDOC als protected gekennzeichnet. That's it.

Mathias

[jobo]

Hallo,

OOP heißt für mich erst einmal, dass es Objekte als Gruppierungen von Daten und Funktionalität gibt und diese Objekte einander Nachrichten senden: »Alan Kay coined the phrase Object-Oriented Programming, but this is not his fault. He has repeatedly said that to him, OOP is about encapsulation and message passing, not inheritance and ontologies of types.« (Quelle)

und genau das ist das Problem von JS. Die Kapselung erfolgt nicht so, dass sie für einen OO Ansatz wirklich verwendbar ist.

Das geht nicht:

function MyClass(){

var private;
}

MyClass.prototype.myFunction = function() {
alert(private);
};

>   
> Und damit ist die Kapselung hinfällig oder du musst den Umweg über ein zusätzliches closure gehen.  
>   
> Darum ging es in der vorgestellten Bibliothek von Florian und darum ging es mir in der Diskussion.  
  
hatten wir [David Aurelios Artikel](http://uxebu.com/blog/2011/02/23/object-based-inheritance-for-ecmascript-5/) hier auch schon mal verlinkt?  
  
Gruß  
  
jobo

[jobo]

Hallo,

OOP heißt für mich erst einmal, dass es Objekte als Gruppierungen von Daten und Funktionalität gibt und diese Objekte einander Nachrichten senden: »Alan Kay coined the phrase Object-Oriented Programming, but this is not his fault. He has repeatedly said that to him, OOP is about encapsulation and message passing, not inheritance and ontologies of types.« (Quelle)

und genau das ist das Problem von JS. Die Kapselung erfolgt nicht so, dass sie für einen OO Ansatz wirklich verwendbar ist.

Das geht nicht:

function MyClass(){

var private;
}

MyClass.prototype.myFunction = function() {
alert(private);
};

> >   
  
Was ich hier nicht verstehe ist, warum du denn im Nachhinein einen Prototyp ändern willst. Das wäre ja so, als wenn du eine Klasse änderst, nachdem du eine Instanz erstellt hast.  

>   
> hatten wir [David Aurelios Artikel](http://uxebu.com/blog/2011/02/23/object-based-inheritance-for-ecmascript-5/) hier auch schon mal verlinkt?  
  
Glaube nicht, hatte die nested Ansicht daraufhin durchforstet. Und auf der Suche nach Ducktyping und Javascript kam noch [dieser Artikel von Nick Fitzgerald über OOP ohne Vererbung raus](http://fitzgeraldnick.com/weblog/39/):  
  
"To conclude, we should recognize that OOP does not need to be an all or nothing proposition. You can take the parts that are beneficial to you (such as message passing, encapsulation, and composition) and leave the parts which you may not require (such as inheritance).  
  
Finally, take everything I say with a grain of salt (as you should with everything you read on the internet)."  
  
  
Gruß  
  
jobo

[JürgenB]

Hallo jobo,

Das geht nicht:

function MyClass(){

var private;
}

MyClass.prototype.myFunction = function() {
alert(private);
};

> > >   
>   
> Was ich hier nicht verstehe ist, warum du denn im Nachhinein einen Prototyp ändern willst. Das wäre ja so, als wenn du eine Klasse änderst, nachdem du eine Instanz erstellt hast.  
  
es geht nicht darum, einen Prototypen zu verändern, sondern darum, ein Objekt nachträglich zu erweitern. Und es geht vor allem darum, dass  
  
~~~javascript
obj = function() {  
  this.objMethode = function() { ... }  
  ...  
}

etwas anderes ist, als

obj = function() {  
  ...  
}  
obj.prototype.objMethode = function() { ... }

Gruß, Jürgen

[jobo]

Hallo,

es geht nicht darum, einen Prototypen zu verändern, sondern darum, ein Objekt nachträglich zu erweitern. Und es geht vor allem darum, dass

obj = function() {

this.objMethode = function() { ... }
  ...
}

>   
> etwas anderes ist, als  
>   
> ~~~javascript

obj = function() {  

>   ...  
> }  
> obj.prototype.objMethode = function() { ... }

"Prototype is the template of the class; which applies to all future instances of it. Whereas this is the particular instance of the object.
"

"I believe that @Matthew Crumley is right. They are functionally, if not structurally, equivalent. If you use Firebug to look at the objects that are created using new, you can see that they are the same. However, my preference would be the following. I'm guessing that it just seems more like what I'm used to in C#/Java. That is, define the class, define the fields, constructor, and methods."

oder auch nicht?

Gruß

jobo

[Don P]

Hallo,

Die Kapselung erfolgt nicht so, dass sie für einen OO Ansatz wirklich verwendbar ist.

Das geht nicht:

function MyClass(){

var private;
}

MyClass.prototype.myFunction = function() {
alert(private);
};

  
Aber das geht:  
  
~~~javascript
function MyClass(){  
var private;  
}  
  
MyClass.prototype.myFunction = function() {  
alert(this.private);  
};  

Es ist doch klar, dass bei

function() { alert(private); }

die JS-Engine nicht wissen kann, was denn nun "private" überhaupt sein soll.
Man muss schon dazusagen, dass eine Eigenschaft des Objekts gemeint ist und nicht etwa eine globale Variable oder sonstwas.

Ich persönlich empfinde es überigens als Glück, dass ich meine ersten OOP-Schritte mit javascript gemacht habe und nicht einer klassischen OOP-Sprache. Inzwischen programmiere ich in C# und habe so meine kleinen Schwierigkeiten damit. Auf die Frage, wie denn nun mit der Sprache klarkomme, fiel meine Antwort entsprechend aus: "Ganz gut, aber manchmal ist sie mir zu sharp", was v.a. auf die Typsicherheit abzielte und auch auf die strengen Klassen, die man nicht einfach mal erweitern kann.
Als Javascriptler kommt mir die extreme Typsicherheit manchmal schlicht pedantisch vor. Die ständigen Meldungen wie "es existiert keine implizierte Umwandlung von int in string" gehen mir ziemlich auf den Wecker ;) musste in einer Anwendung als Workaround sogar schon auf ((√x)²)/y zurückgreifen, nur weil ich x/y eine Dezimalzahl brauchte *kopfpatsch*.

Gruß, Don P

[jobo]

Hallo,

Das geht nicht:

function MyClass(){

var private;
}

MyClass.prototype.myFunction = function() {
alert(private);
};

>   
> Aber das geht:  
>   
> ~~~javascript

function MyClass(){  

> var private;  
> }  
>   
> MyClass.prototype.myFunction = function() {  
> alert(this.private);  
> };  
> 

Das "geht" nicht, würde ich meinen. Denn this.private ist "undefined".

  
function myClass () {  
	var myPrivate = "privaterWert";  
		this.showThisPrivate = function () {  
			alert(myPrivate);  
	}  
}  
myClass.prototype.showPrototypePrivate = function () {  
	alert(this.myPrivate);  
}  
myInstance = new myClass();  
myInstance.showPrototypePrivate(); //undefined , weil this.myPrivate nicht existiert  
myInstance.showThisPrivate(); //"privaterWert" weil die Funktion wegen closure zugreifen kann  
alert(myInstance.myPrivate); //undefined weil, wie Beispiel 1, this.myPrivat nicht existiert  

Struppi nennt das zwar "lokale" variable, da sie aber für alle Klassenfunktionen zugänglich ist, nennen andere sie "private" Variablen. Weil sich eben nur über Klassenfunktionen (getter und setter), nicht aber über Prototype  zugreifen lässt.

Gruß

jobo

[Don P]

Hallo,

Das "geht" nicht, würde ich meinen. Denn this.private ist "undefined".

Ok, ich hatte es so probiert:

  
function MyClass(){ var private; }  
// Instanz erzeugen:  
var myInstance = new MyClass;  
// Testweise einen Wert zuweisen (mein Denkfehler):  
myInstance.private = 1;  
// Klasse erweitern:  
MyClass.prototype.myFunction = function() { alert(this.private); };  
// Neue Methode anwenden:  
alert(myInstance.private); // 1  

Aber das ist anscheinend nicht dasselbe. "private" soll ja anscheinend gar keine Eigenschaft sein, sondern eben eine private Variable. Stimmt, dann kann man von außen natürlich nicht mehr zugreifen, auch nachträglich über den prototype angelegte Methoden können das nicht.

Wenn man trotzdem zugreifen will, bemüht man eben Getter und Setter, wobei sich mir der Sinn dessen nicht ganz erschließt. Dann kann man ja gleich eine normale Eigenschaft anlegen. Entweder man will von außen zugreifen können oder eben nicht. Dieses Get/Set kommt mir vor, als könne man sich nicht richig entscheiden: Ja, ich will zugreifen können, aber nur über Mittelsmänner, die Variable selber will ich nicht direkt anfassen – zu dreckig? zu unwürdig? oder wie ;) ?.

Gruß, Don P

[Struppi]

Wenn man trotzdem zugreifen will, bemüht man eben Getter und Setter, wobei sich mir der Sinn dessen nicht ganz erschließt.

Auch darum geht es nicht. Nochmal es ging um klassenweite private Variabeln. Also nicht um wleche die von aussen sichtbar sein müssen.

Dann kann man ja gleich eine normale Eigenschaft anlegen. Entweder man will von außen zugreifen können oder eben nicht. Dieses Get/Set kommt mir vor, als könne man sich nicht richig entscheiden: Ja, ich will zugreifen können, aber nur über Mittelsmänner, die Variable selber will ich nicht direkt anfassen – zu dreckig? zu unwürdig? oder wie ;) ?.

Warum das so ist, ist eine Grundlage der OOP. Wenn du nicht OO programmierst, brauchst du vielleicht keine Kapselung.

Struppi.

[Don P]

Hallo,

Wenn man trotzdem zugreifen will, bemüht man eben Getter und Setter, wobei sich mir der Sinn dessen nicht ganz erschließt.

Auch darum geht es nicht. Nochmal es ging um klassenweite private Variabeln. Also nicht um wleche die von aussen sichtbar sein müssen.

Dein Beispiel läuft aber darauf hinaus. Wenn du verlangst, dass Methoden eines neu zugewiesenen Prototyps auf die private Variable zugreifen können sollen, dann ist das nunmal "von außen". Zur Zeit der Zuweisung des Prototyps sind die Variablen bereits privat. Eine Halbprivatheit gibt es nunmal nicht.

Klassenweite private Variablen kann man in JavaScript doch haben, nur nicht durch nachträglich eingeführte Methoden darauf zugreifen. Muss das überhaupt sein? Geht das in anderen OO-Sprachen? In C# z.B. kann man partielle Klassen deklarieren, aber zur Laufzeit neue Methoden einführen? Die dann auch noch Zugriff auf die privaten Variablen haben? Nicht das ich wüsste...

Warum das so ist, ist eine Grundlage der OOP. Wenn du nicht OO programmierst, brauchst du vielleicht keine Kapselung.

Kaplselung brauche ich auch manchmal. Closures funktioniern für meine Zwecke wunderbar, und ich ich sehe sie auch nicht als Umweg. Ist denn z.B. ein Get/Set oder eine private Klassenvariable wirklich etwas anderes als eine Closure?

Gruß, Don P

[Struppi]

Wenn man trotzdem zugreifen will, bemüht man eben Getter und Setter, wobei sich mir der Sinn dessen nicht ganz erschließt.

Auch darum geht es nicht. Nochmal es ging um klassenweite private Variabeln. Also nicht um wleche die von aussen sichtbar sein müssen.

Dein Beispiel läuft aber darauf hinaus. Wenn du verlangst, dass Methoden eines neu zugewiesenen Prototyps auf die private Variable zugreifen können sollen, dann ist das nunmal "von außen". Zur Zeit der Zuweisung des Prototyps sind die Variablen bereits privat. Eine Halbprivatheit gibt es nunmal nicht.

Bingo, du hast verstanden was ich sagen wollte.

Warum das so ist, ist eine Grundlage der OOP. Wenn du nicht OO programmierst, brauchst du vielleicht keine Kapselung.

Kaplselung brauche ich auch manchmal. Closures funktioniern für meine Zwecke wunderbar, und ich ich sehe sie auch nicht als Umweg. Ist denn z.B. ein Get/Set oder eine private Klassenvariable wirklich etwas anderes als eine Closure?

Wie auch bereits gesagt, dieser Thread handelt nicht davon, ob und wie man irgend etwas mit JS lösen kann oder nicht. Sondern darum, dass ein Framework/Bibliothek vorgestellt wurde, das versucht private/protected/public in JS zu simulieren.

Struppi.

[Don P]

Hallo,

Wie auch bereits gesagt, dieser Thread handelt nicht davon, ob und wie man irgend etwas mit JS lösen kann oder nicht. Sondern darum, dass ein Framework/Bibliothek vorgestellt wurde, das versucht private/protected/public in JS zu simulieren.

Äh, das verstehe ich nicht. Beim Versuch das zu simulieren geht es doch genau darum, "ob und wie man irgend etwas mit JS lösen kann", und falls es möglich ist, ob das etwa umständlicher ist als sonst.

Ich hatte mich auf deine plakative Aussage bezogen:

Die Kapselung erfolgt nicht so, dass sie für einen OO Ansatz wirklich verwendbar ist.

Deshalb habe ich nachgefragt, ob denn private Variablen mit dem üblichen Get/Set (wie z.B. in C#) etwas anderes sind als Closures mit Getter/Setter in JavaScript. Außer der konkreten Syntax ist es doch dasselbe. Getter/Setter in JS sind m.E. nicht aufwändiger, schließlich muss man solche in anderen Sprachen auch notieren, oder stimmt das nicht?
Und solche "halbprivaten" Variablen wie von dir im Beispiel verlangt, gibt es doch in anderen Sprachen auch nicht, oder vielleicht doch? Wenn nicht, wären die für einen OO-Ansatz ebensowenig geeignet.

Im Fall von Closures mit Getter/Setter ist es m.E. kein Simulieren von klassischem OO-Verhalten, sondern tatsächlich dasselbe, nur mit etwas anderer Syntax, was man einer Programmiersprache wohl zugestehen darf.

Gruß, Don P

[Struppi]

Wie auch bereits gesagt, dieser Thread handelt nicht davon, ob und wie man irgend etwas mit JS lösen kann oder nicht. Sondern darum, dass ein Framework/Bibliothek vorgestellt wurde, das versucht private/protected/public in JS zu simulieren.

Äh, das verstehe ich nicht. Beim Versuch das zu simulieren geht es doch genau darum, "ob und wie man irgend etwas mit JS lösen kann", und falls es möglich ist, ob das etwa umständlicher ist als sonst.

Genau um dieses thema sollte sich der Thread ursprünglich dregen.

Aber an der Stelle wo du jetzt eingestiegen bist, ging es nur noch um die Grundsätzliche Behauptung von mir, dass es mit JS schwierig ist, ein strengeres OO Konzept umzusetzen. Weil ich dies als Argument für den Aufwand einer solchen Bibliothek gebracht habe.

Ich hatte mich auf deine plakative Aussage bezogen:

Die Kapselung erfolgt nicht so, dass sie für einen OO Ansatz wirklich verwendbar ist.

Deshalb habe ich nachgefragt, ob denn private Variablen mit dem üblichen Get/Set (wie z.B. in C#) etwas anderes sind als Closures mit Getter/Setter in JavaScript. Außer der konkreten Syntax ist es doch dasselbe.

Weiß ich nicht, ich kenn mich mit C# nicht aus. Wie auch immer, es geht nicht um getter/setter. Es geht um die Gültigkeit der Variabel. In JS ist diese Funktionsweit, es gibt keine Klassenweite Variabeln.

Und solche "halbprivaten" Variablen wie von dir im Beispiel verlangt, gibt es doch in anderen Sprachen auch nicht, oder vielleicht doch? Wenn nicht, wären die für einen OO-Ansatz ebensowenig geeignet.

Doch sie gibt es. Ich verlange auch keine Halbprivaten Variabeln, sondern das war Pseudocode, der zeigen sollte, dass es in JS keine echte Klassenweiten privaten Variabeln gibt.

Im Fall von Closures mit Getter/Setter ist es m.E. kein Simulieren von klassischem OO-Verhalten, sondern tatsächlich dasselbe, nur mit etwas anderer Syntax, was man einer Programmiersprache wohl zugestehen darf.

Es ist ein Unterschied, ob du in der Konstruktorfunktion eine Memberfunktion deklarierst (was du musst, wenn du mit echten privaten Werten arbeiten willst) oder ob du diese dem prototype des Konstruktors zuweist.

Das ist für mich ein simulieren einer privaten Klassenvariabeln, durch die Fähigkeit von JS, zur Laufzeit Funktionen an die Instanz hinzuzufügen. Hat aber den Nachteil eines langsameren Konstruktors, eines unübersichtlichen Konstruktor und dass alle Funktionen, die ebenfalls auf diese Variabel zugreifen können sollen, ebenfalls innerhalb des Konstruktors definiert werden müssen.

Deshalb muss man sich bei wirklich Geschwindigkeitsrelevanten Anwendungsfällen überlegen, ob man nicht lieber auf die strenge Kapselung verzichtet und eine durch Namenskonvention pseudo private Variabel verwendet, da dies deutlich schneller ist.

Struppi.

[molily]

Deshalb muss man sich bei wirklich Geschwindigkeitsrelevanten Anwendungsfällen überlegen, ob man nicht lieber auf die strenge Kapselung verzichtet und eine durch Namenskonvention pseudo private Variabel verwendet, da dies deutlich schneller ist.

Ich weiß nicht, ob ich es nicht schon hier im Thread verlinkt habe:
http://www.aminutewithbrendan.com/pages/20110216

Brendan Eich meint, dass sich die JS-Programmierer darüber nicht unnötig den Kopf zerbrechen sollten und es mehr die Aufgabe der JS-Engine-Entwickler sei, das so zu optimieren, dass sich letztlich nur noch wenige Unterschiede ergeben.
Das heißt natürlich nicht, dass das Prototype-Pattern derzeit nicht schneller ist. Aber aus bloßer Angst auf Kapselung zu verzichten hält er für »Premature Optimization«. Er plädiert daher für Kapselung, wenn es einem hilft. Wenn sich das im Nachhinein beim Profiling als signifikante Performance-Bremse herausstellt, kann man immer noch optimieren und ggf. zur Prototyp-Lösung wechseln.

Mathias

[jobo]

Hallo,

Deshalb muss man sich bei wirklich Geschwindigkeitsrelevanten Anwendungsfällen überlegen, ob man nicht lieber auf die strenge Kapselung verzichtet und eine durch Namenskonvention pseudo private Variabel verwendet, da dies deutlich schneller ist.

Ich weiß nicht, ob ich es nicht schon hier im Thread verlinkt habe:
http://www.aminutewithbrendan.com/pages/20110216

Brendan Eich meint, dass sich die JS-Programmierer darüber nicht unnötig den Kopf zerbrechen sollten und es mehr die Aufgabe der JS-Engine-Entwickler sei, das so zu optimieren, dass sich letztlich nur noch wenige Unterschiede ergeben.
Das heißt natürlich nicht, dass das Prototype-Pattern derzeit nicht schneller ist. Aber aus bloßer Angst auf Kapselung zu verzichten hält er für »Premature Optimization«. Er plädiert daher für Kapselung, wenn es einem hilft. Wenn sich das im Nachhinein beim Profiling als signifikante Performance-Bremse herausstellt, kann man immer noch optimieren und ggf. zur Prototyp-Lösung wechseln.

Um das Beispiel geht es ja:

  
// Are these two patterns the same performance/memory-wise  
  
function MyConstructor() {  
    function someMethod() {  
        console.log('foo');  
    }  
}  
var instanceA = new MyConstructor();  
  
function OtherConstructor() {}  
OtherConstructor.prototype = {  
    someMethod: function () {  
        console.log('foo');  
    }  
}  
var instanceB = new OtherConstructor();  

Logisch scheint ja, dass bei häufigem Aufruf von MyConstructor immer wieder die Methode mit definiert wird. Statt dass sich viele von MyConstructor abgeleitete Objekte auf _eine_ Prototyp.Methode beziehen. Wobei die Frage vielleicht erlaubt ist, wer denn so viele Objekt(instanzen) braucht.

Die Prototypkette ist nur beim ersten Aufruf etwas lahmer, weil anschließen gecached wird. Wenn ich das jetzt richtig rausgehört habe.

Gruß

jobo

[jobo]

Hallo,

Weiß ich nicht, ich kenn mich mit C# nicht aus. Wie auch immer, es geht nicht um getter/setter. Es geht um die Gültigkeit der Variabel. In JS ist diese Funktionsweit, es gibt keine Klassenweite Variabeln.

Naja, das liegt aber daran, dass die Klasse als Funktion definiert wird. Wenn man mit "new" arbeitet.

Es ist ein Unterschied, ob du in der Konstruktorfunktion eine Memberfunktion deklarierst (was du musst, wenn du mit echten privaten Werten arbeiten willst)

... und mit Javascript auch kannst ...;

oder ob du diese dem prototype des Konstruktors zuweist.
Das ist für mich ein simulieren einer privaten Klassenvariabeln,

Nein, da kannst du ja nicht mehr auf die private Variable zugreifen.

https://forum.selfhtml.org/?t=203423&m=1377121. Du kannst private Variablen nicht simulieren. Entweder du sie sind im Functionscope nach außen nicht sichtbar. Oder sie sind nach außen sichtbar. Nichts anderes ist "privat". Aus meiner Sicht. "privat" === "nach außen nicht sichtbar" === "von außen nicht direkt zugreifbar".

Gruß

jobo

[jobo]

Hallo,

http://forum.de.selfhtml.org/my/?t=203423&m=1377121. Du kannst private Variablen nicht simulieren. Entweder du sie sind im Functionscope nach außen nicht sichtbar. Oder sie sind nach außen sichtbar. Nichts anderes ist "privat". Aus meiner Sicht. "privat" === "nach außen nicht sichtbar" === "von außen nicht direkt zugreifbar".

s.a. diesen Artikel zum YUI.Module-Pattern mit privaten Variablen und privaten Methoden (falls wir das nicht schon hatten (;-)).

Gruß

jobo

[Struppi]

https://forum.selfhtml.org/?t=203423&m=1377121. Du kannst private Variablen nicht simulieren. Entweder du sie sind im Functionscope nach außen nicht sichtbar. Oder sie sind nach außen sichtbar. Nichts anderes ist "privat". Aus meiner Sicht. "privat" === "nach außen nicht sichtbar" === "von außen nicht direkt zugreifbar".

Das ist deine Sichtweise, mir geht es um private Variabeln die in der Klasse sichtbar sind und das kann man simluieren:

var MyClass = (function() {  
var private;  
function Proto(){}  
Proto.prototype.func = function() {return private;};  
Proto.prototype.tu_was = function(p) {private = p * p;};  
return Proto;  
})();  
  
var c = new MyClass();  
c.tu_was(2);  
alert(c.func());

Struppi.

[jobo]

Hallo,

http://forum.de.selfhtml.org/my/?t=203423&m=1377121. Du kannst private Variablen nicht simulieren. Entweder du sie sind im Functionscope nach außen nicht sichtbar. Oder sie sind nach außen sichtbar. Nichts anderes ist "privat". Aus meiner Sicht. "privat" === "nach außen nicht sichtbar" === "von außen nicht direkt zugreifbar".

Das ist deine Sichtweise, mir geht es um private Variabeln die in der Klasse sichtbar sind und das kann man simluieren:

var MyClass = (function() {

var private;
function Proto(){}
Proto.prototype.func = function() {return private;};
Proto.prototype.tu_was = function(p) {private = p * p;};
return Proto;
})();

var c = new MyClass();
c.tu_was(2);
alert(c.func());

>   
> Struppi.  
  
Das ist keine Simulation. Das ist die Umsetzung eines Konzeptes. Hatte ich eben schon verlinkt, hier der Auszug:  
  
~~~javascript
  
YAHOO.myProject.myModule = function () {  
  
	//"private" variables:  
	var myPrivateVar = "I can be accessed only from within YAHOO.myProject.myModule.";  
  
	//"private" method:  
	var myPrivateMethod = function () {  
		YAHOO.log("I can be accessed only from within YAHOO.myProject.myModule");  
	}  
  
	return  {  
		myPublicProperty: "I'm accessible as YAHOO.myProject.myModule.myPublicProperty.",  
		myPublicMethod: function () {  
			YAHOO.log("I'm accessible as YAHOO.myProject.myModule.myPublicMethod.");  
  
			//Within myProject, I can access "private" vars and methods:  
			YAHOO.log(myPrivateVar);  
			YAHOO.log(myPrivateMethod());  
  
			//The native scope of myPublicMethod is myProject; we can  
			//access public members using "this":  
			YAHOO.log(this.myPublicProperty);  
		}  
	};  
  
}(); // the parens here cause the anonymous function to execute and return  

aus http://www.yuiblog.com/blog/2007/06/12/module-pattern/.

"Douglas Crockford has been teaching a useful singleton pattern for achieving this discipline, and I thought his pattern might be of interest to those of you building on top of YUI. Douglas calls this the “module pattern.”

Gruß

jobo

[jobo]

Hallo,

aus http://www.yuiblog.com/blog/2007/06/12/module-pattern/.

"Douglas Crockford has been teaching a useful singleton pattern for achieving this discipline, and I thought his pattern might be of interest to those of you building on top of YUI. Douglas calls this the “module pattern.”

Hier noch ein Artikel, der auch das "Module Pattern" einschließt

Gruß

jobo

[peterS.]

gruss jobo,

siehst Du den unterschied zwischen Struppis "sprechendem code"
und dem ebenso "spechenden code", den Du zitierst?

Struppi kapselt den >>Constructor<< [Proto] zusammen mit [private]
in einem module pattern und referenziert diesen dann anschliessend
auf die variable [MyClass].

das von Dir zitierte bsp. erzeugt ueber das module pattern ein

Object<< und gibt dieses zurueck.

gemeinsam ist beiden beispielen das module pattern.

am ende liegt Struppi so nahe an einem klassen-emulierenden
ergebnis wie in JavaScript eben moeglich.

dein bsp. zeigt das module pattern in seiner auspraegung als
singleton generator.

Kapselung<< ist ein grundlegendes OOP-merkmal. in JavaScript

erreicht man dies auf genau einem Weg - ueber function scopes.

Das ist keine Simulation. Das ist die Umsetzung eines Konzeptes.
...

richtig. (Closures) sind neben [prototype] ein grundlegendes
konzept von JavaScript. aber sachen in closures hineinzustecken
und irgendetwas anderes zurueckzugeben haben entwickler schon
lange vor 2007 (und auch vor Crockford) getan. Richard Cornford
(2004?)ist uebrigens der vater des von Struppi vorgestellten
"ich will Klassen"-Ansatzes.

so long - peterS. - [e-mail]

[jobo]

Hallo,

siehst Du den unterschied zwischen Struppis "sprechendem code"
und dem ebenso "spechenden code", den Du zitierst?

Na kaum (außer wie von Dir beschrieben) denn die Kapselung erfolgt ja, bei Javascript via Closure. Ob dies ein "Umweg" ist, scheint ja Interpretationssache.

Kapselung<< ist ein grundlegendes OOP-merkmal. in JavaScript
erreicht man dies auf genau einem Weg - ueber function scopes.

Ja, da sind wir uns glaube ich alle einig. Ich verstehe oder verstand Struppi halt so, dass das bei Javascript eben kein "richtiges" OOP ist. Bitte nicht persönlich nehmen, ich interpretiere jetzt "und genau das ist das Problem von JS. Die Kapselung erfolgt nicht so, dass sie für einen OO Ansatz wirklich verwendbar ist."

Und dazu passt auch wieder diese Passage von eben:

Das ist keine Simulation. Das ist die Umsetzung eines Konzeptes.
...

richtig. (Closures) sind neben [prototype] ein grundlegendes
konzept von JavaScript. aber sachen in closures hineinzustecken
und irgendetwas anderes zurueckzugeben haben entwickler schon
lange vor 2007 (und auch vor Crockford) getan. Richard Cornford
(2004?)ist uebrigens der vater des von Struppi vorgestellten
"ich will Klassen"-Ansatzes.

Ja, wobei es ja nun nicht wirklich darum geht, wer was erfunden hat, sondern was wie machbar ist. Und Kapselung ist machbar. Also ist Objektorientierung möglich (ob nun mit "Umweg" oder nicht scheint ja Ansichtssache). Sagt ja irgendwie auch Wikipedia. Und dass die Meinungen da auseinandergehen ist ja in dem einen Artikel schön zusammengefasst, wie ich fand.

Gruß

jobo

[Struppi]

siehst Du den unterschied zwischen Struppis "sprechendem code"
und dem ebenso "spechenden code", den Du zitierst?

Na kaum (außer wie von Dir beschrieben) denn die Kapselung erfolgt ja, bei Javascript via Closure. Ob dies ein "Umweg" ist, scheint ja Interpretationssache.

Das stimmt, wenn du ein zusätzliches closure nicht als Umweg siehst, dann ist es eben keiner. Aber letztlich kannst du nicht bestreiten, dass JS keine Klassenweite Gültigkeit von Variabeln definieren kann.

Ja, da sind wir uns glaube ich alle einig. Ich verstehe oder verstand Struppi halt so, dass das bei Javascript eben kein "richtiges" OOP ist. Bitte nicht persönlich nehmen, ich interpretiere jetzt "und genau das ist das Problem von JS. Die Kapselung erfolgt nicht so, dass sie für einen OO Ansatz wirklich verwendbar ist."

Ja, weil sie sich eben nicht auf Klassen anwenden läßt. Es ist eben ein Unterschied, ob du Variabeln private deklarierst oder lokal, JS kennt diesen Unterschied nicht.

Ja, wobei es ja nun nicht wirklich darum geht, wer was erfunden hat, sondern was wie machbar ist. Und Kapselung ist machbar. Also ist Objektorientierung möglich (ob nun mit "Umweg" oder nicht scheint ja Ansichtssache). Sagt ja irgendwie auch Wikipedia. Und dass die Meinungen da auseinandergehen ist ja in dem einen Artikel schön zusammengefasst, wie ich fand.

Der Artikel beschreibt die Prototypische Vererbung, damit habe ich kein Problem. Nur damit, dass ich mir immer überlegen muss, wie private Member Kapseln sollte. Entweder ich habe u.U. Geschwindigkeitseinbußen oder keine Kapselung.

Struppi.

[jobo]

Hallo,

siehst Du den unterschied zwischen Struppis "sprechendem code"
und dem ebenso "spechenden code", den Du zitierst?

Na kaum (außer wie von Dir beschrieben) denn die Kapselung erfolgt ja, bei Javascript via Closure. Ob dies ein "Umweg" ist, scheint ja Interpretationssache.

Das stimmt, wenn du ein zusätzliches closure nicht als Umweg siehst, dann ist es eben keiner. Aber letztlich kannst du nicht bestreiten, dass JS keine Klassenweite Gültigkeit von Variabeln definieren kann.

molily nennt das "emulieren".

Der Artikel beschreibt die Prototypische Vererbung, damit habe ich kein Problem. Nur damit, dass ich mir immer überlegen muss, wie private Member Kapseln sollte. Entweder ich habe u.U. Geschwindigkeitseinbußen oder keine Kapselung.

Naja, von Geschwindigkeit war ja eher am Rande die Rede. Es ging ja eher um die Umsetzung eines Prinzips. Mit der "Performance " hat sich Mathias in o.g. Artikel ja auch intensiv beschäftigt.

Gruß

jobo

[Struppi]

siehst Du den unterschied zwischen Struppis "sprechendem code"
und dem ebenso "spechenden code", den Du zitierst?

Na kaum (außer wie von Dir beschrieben) denn die Kapselung erfolgt ja, bei Javascript via Closure. Ob dies ein "Umweg" ist, scheint ja Interpretationssache.

Das stimmt, wenn du ein zusätzliches closure nicht als Umweg siehst, dann ist es eben keiner. Aber letztlich kannst du nicht bestreiten, dass JS keine Klassenweite Gültigkeit von Variabeln definieren kann.

molily nennt das "emulieren".

Was eine ähnliche Bedeutung wie simulieren hat.

Der Artikel beschreibt die Prototypische Vererbung, damit habe ich kein Problem. Nur damit, dass ich mir immer überlegen muss, wie private Member Kapseln sollte. Entweder ich habe u.U. Geschwindigkeitseinbußen oder keine Kapselung.

Naja, von Geschwindigkeit war ja eher am Rande die Rede. Es ging ja eher um die Umsetzung eines Prinzips. Mit der "Performance " hat sich Mathias in o.g. Artikel ja auch intensiv beschäftigt.

Du verwechselst wieder etwas. Es geht nicht um die Geschwindigkeit von closures. In meinem Beispiel, hat das closure nur eine untergeordnete Rolle und so gut wie kein Performance Nachteil. Allerdings ist dieser Weg eher selten.

Den Nachteil hast du erst, wenn du im Konstruktor mit this.func = function() {} eine Funktion der Instanz hinzufügst.

Struppi.

[jobo]

Hallo,

Du verwechselst wieder etwas. Es geht nicht um die Geschwindigkeit von closures. In meinem Beispiel, hat das closure nur eine untergeordnete Rolle und so gut wie kein Performance Nachteil. Allerdings ist dieser Weg eher selten.

Den Nachteil hast du erst, wenn du im Konstruktor mit this.func = function() {} eine Funktion der Instanz hinzufügst.

Nein, kapiere ich wirklich nicht. Mit dem "module pattern" brauche ich this zwar nicht, aber vielleicht kannst Du ja noch irgendwas verlinken, wo erklärt wird, wo der Performanceverlust durch "this" erzeugt wird, unabhängig vom Closure. Denn this.member hat ja nix mir dem Thema "privat" zu tun. "privat" aber wieder geht ohne Closure nicht. Insofern zwei Paar Schuhe, würde ich meinen.

Gruß

jobo

[Struppi]

Du verwechselst wieder etwas. Es geht nicht um die Geschwindigkeit von closures. In meinem Beispiel, hat das closure nur eine untergeordnete Rolle und so gut wie kein Performance Nachteil. Allerdings ist dieser Weg eher selten.

Den Nachteil hast du erst, wenn du im Konstruktor mit this.func = function() {} eine Funktion der Instanz hinzufügst.

Nein, kapiere ich wirklich nicht. Mit dem "module pattern" brauche ich this zwar nicht, aber vielleicht kannst Du ja noch irgendwas verlinken, wo erklärt wird, wo der Performanceverlust durch "this" erzeugt wird, unabhängig vom Closure. Denn this.member hat ja nix mir dem Thema "privat" zu tun. "privat" aber wieder geht ohne Closure nicht. Insofern zwei Paar Schuhe, würde ich meinen.

Natürlich, jede Variabel in einer Funktion ist privat bzw. lokal, das closure ist nur eine zusätzliche Ebene.

Es geht um diesen Unterschied:

function MyClass() {  
this._private;  
}  
MyClass.prototype.func = function() {return this._private;};  
MyClass.prototype.tu_was = function(p) {this._private = p * p;};  
var x = new MyClass();  

function MyClass() {  
var private;  
this.func = function() {return private;};  
this.tu_was = function(p) {private = p * p;};  
}  
var x = new MyClass();  

Das erste ist je nach Browser 2-4 Mal schneller, man möchte aber das zweite, wenn es um konsequente Umsetzung der Kapselung geht.

Struppi.

[jobo]

Hallo,

Es geht um diesen Unterschied:

function MyClass() {

this._private;
}
MyClass.prototype.func = function() {return this._private;};
MyClass.prototype.tu_was = function(p) {this._private = p * p;};
var x = new MyClass();

>   
> ~~~javascript

function MyClass() {  

> var private;  
> this.func = function() {return private;};  
> this.tu_was = function(p) {private = p * p;};  
> }  
> var x = new MyClass();  
> 

Ähm, das liegt doch daran, dass diese Variable "private" durch das Closure konserviert werden muss. Der Performanceverlust, wie von molily in dem vorhin verlinkten Artikel beschrieben, entsteht durch den Einsatz des Closure. Dabei ist es nämlich recht egal, ob damit was OOP-mäßiges machst oder eine Funktion zurückgibst, die sich auf diese eingeschlossene Variable bezieht. Nicht dass wir jetzt wieder über Begrifflichkeitsdefinitionen reden wie "Umweg", "Emulation" oder "Simulation". Ich _verstehe_, dass man diese Begriffen unterschieliche Bedeutungen geben kann oder auch nicht. Insofern gehts mir hier eher darum, ob ich da noch etwas JS-spezifisches nicht kapiert habe. O.g., wie eben erläutert, scheint mir zumindest kein Teil eines Missverständnisses zu sein.

Gruß

jobo

[Struppi]

Hallo,

Es geht um diesen Unterschied:

function MyClass() {

this._private;
}
MyClass.prototype.func = function() {return this._private;};
MyClass.prototype.tu_was = function(p) {this._private = p * p;};
var x = new MyClass();

> >   
> > ~~~javascript

function MyClass() {  

> > var private;  
> > this.func = function() {return private;};  
> > this.tu_was = function(p) {private = p * p;};  
> > }  
> > var x = new MyClass();  
> > 

Ähm, das liegt doch daran, dass diese Variable "private" durch das Closure konserviert werden muss. Der Performanceverlust, wie von molily in dem vorhin verlinkten Artikel beschrieben, entsteht durch den Einsatz des Closure.

Nein, der Performanceverlust entsteht durch die Zuweisung von this.func = function() {} zur Laufzeit.

Struppi.

[jobo]

Hallo,

» »»

Ähm, das liegt doch daran, dass diese Variable "private" durch das Closure konserviert werden muss. Der Performanceverlust, wie von molily in dem vorhin verlinkten Artikel beschrieben, entsteht durch den Einsatz des Closure.

Nein, der Performanceverlust entsteht durch die Zuweisung von this.func = function() {} zur Laufzeit.

Aber warum dann nicht das verlinkte Module-Pattern?

returned a = {dies:"machdas"} und spart this.dies???

Gruß

jobo

[Don P]

Hallo,

am ende liegt Struppi so nahe an einem klassen-emulierenden
ergebnis wie in JavaScript eben moeglich.

Findest du? Ich sehe in seinem Code

[code lang=javascript]var MyClass = (function() {
var private;
function Proto(){}
Proto.prototype.func = function() {return private;};
Proto.prototype.tu_was = function(p) {private = p * p;};
return Proto;
})();

nur eine eine Closure-Variable, auf die unnötigerweise vom Prototyp aus zugegriffen wird. Viel einfacher ist bei gleicher Leistung doch das übliche

[code lang=javascript]var MyClass = function() {
    var private;
    this.func = function() {return private;};
    this.tu_was = function(p) {private = p * p;};
};

Natürlich kann man auch hier nicht durch nachträgliche Erweiterung (außerhalb des Konstruktors) auf p zugreifen. Beim Erzeugen einer Instanz muss trotzdem immer eine neue Funktion "Proto" angelegt werden.

In der Tat hat man somit eine private Klassenvariable. So notiert man das nunmal in JS. Wie heißt es doch so schön: Wenn etwas aussieht wie eine Ente, schwimmt, quakt und watschelt wie eine Ente, dann *ist* es eine Ente. Also warum von Simulation sprechen?

Gruß, Don P

[jobo]

Hallo,

Hallo,

am ende liegt Struppi so nahe an einem klassen-emulierenden
ergebnis wie in JavaScript eben moeglich.

Findest du? Ich sehe in seinem Code

var MyClass = (function() {

var private;
function Proto(){}
Proto.prototype.func = function() {return private;};
Proto.prototype.tu_was = function(p) {private = p * p;};
return Proto;
})();

>   
> nur eine eine Closure-Variable, auf die unnötigerweise vom Prototyp aus zugegriffen wird.  
  
Tja, das mit dem unnötigerweise ist vielleicht garnicht so verkehrt.  
  
Viel einfacher ist bei gleicher Leistung doch das übliche  

>   
> > ~~~javascript

var MyClass = function() {  

> >     var private;  
> >     this.func = function() {return private;};  
> >     this.tu_was = function(p) {private = p * p;};  
> > };

Natürlich kann man auch hier nicht durch nachträgliche Erweiterung (außerhalb des Konstruktors) auf p zugreifen. Beim Erzeugen einer Instanz muss trotzdem immer eine neue Funktion "Proto" angelegt werden.

Du meinst jetzt bei Struppis Beispiel? Du hast doch in deinem garkeine Proto-Funktion.

In der Tat hat man somit eine private Klassenvariable. So notiert man das nunmal in JS. Wie heißt es doch so schön: Wenn etwas aussieht wie eine Ente, schwimmt, quakt und watschelt wie eine Ente, dann *ist* es eine Ente. Also warum von Simulation sprechen?

Oder "Umweg".

Im Sinne von "speaking code" ist das "revealing module pattern" aber vielleicht auch interessant. Irgendwie gefällt es mir momentan am besten:

  
var myObj = function () {  
	var _privateVar = "privateVarContent",  
	_privateFunction = function () {  
		return "privateFunctionReturn";  
	},  
	publicFunction = function () {  
		return "publicFunctionReturn";  
	};  
	return {  
		getPrivate : function () {  
			return _privateVar + " " + _privateFunction();  
		},  
		publicFunction : publicFunction  
	}  
}();  
alert(myObj.getPrivate());  
alert(myObj.publicFunction());  

Wobei ich hier in der Rückgabe gemixed habe. Eigentlich ist es so wohl noch übersichtlichter/richtiger:

  
var myObj = function () {  
	var _privateVar = "privateVarContent",  
	_privateFunction = function () {  
		return "privateFunctionReturn";  
	},  
	publicFunction = function () {  
		return "publicFunctionReturn";  
	},  
	getPrivate = function () {  
		return _privateVar + " " + _privateFunction();  
	};  
	return {  
		getPrivate : getPrivate,  
		publicFunction : publicFunction  
	}  
}();  
alert(myObj.getPrivate());  
alert(myObj.publicFunction());  

Gruß

jobo

[Struppi]

nur eine eine Closure-Variable, auf die unnötigerweise vom Prototyp aus zugegriffen wird. Viel einfacher ist bei gleicher Leistung doch das übliche

Das mit der gleichen Leistung stimmt nicht, das ist je nach Browser ca. 2-4 Mal langsamer.

Und ich wiederhole mich vermutlich zum 20. Mal, es geht nur darum zu zeigen, dass JS kein Schlüsselwort für private hat und das man dies nur über diesen Umweg simulieren kann.

[code lang=javascript]var MyClass = function() {
    var private;
    this.func = function() {return private;};
    this.tu_was = function(p) {private = p * p;};
};

In der Tat hat man somit eine private Klassenvariable.

Nein jhat man nicht, du hast ein private Variabel im Konstruktor, auf die priviligierte Funktionen zugreifen können. Alle Funktionen am protoype, können nicht darauf zugreifen. Genau darum ging es im Beispiel.

Struppi.

[jobo]

Hallo,

Hallo,

Wenn man trotzdem zugreifen will, bemüht man eben Getter und Setter, wobei sich mir der Sinn dessen nicht ganz erschließt.

Auch darum geht es nicht. Nochmal es ging um klassenweite private Variabeln. Also nicht um wleche die von aussen sichtbar sein müssen.

Dein Beispiel läuft aber darauf hinaus. Wenn du verlangst, dass Methoden eines neu zugewiesenen Prototyps auf die private Variable zugreifen können sollen, dann ist das nunmal "von außen". Zur Zeit der Zuweisung des Prototyps sind die Variablen bereits privat. Eine Halbprivatheit gibt es nunmal nicht.

Die gibt es ja in Klassendefinitionen auch nicht.

  
<?php  
class myClass {  
	private $_private = "privat";  
	public $publicVar = "public";  
	function getPrivate() {  
		return $this->_private;  
	}  
}  
$myInstance = new myClass;  
//echo $myInstance->_private; //Fatal Error - Cannot access private Property  
echo $myInstance->publicVar; //"public";  
echo $myInstance->getPrivate(); //"privat"  

PHP und andere kennen noch "protected". Denn "private" lässt sich nicht vererben.

Klassenweite private Variablen kann man in JavaScript doch haben, nur nicht durch nachträglich eingeführte Methoden darauf zugreifen. Muss das überhaupt sein? Geht das in anderen OO-Sprachen? In C# z.B. kann man partielle Klassen deklarieren, aber zur Laufzeit neue Methoden einführen? Die dann auch noch Zugriff auf die privaten Variablen haben? Nicht das ich wüsste...

Warum das so ist, ist eine Grundlage der OOP. Wenn du nicht OO programmierst, brauchst du vielleicht keine Kapselung.

@Struppi: Du weißt doch, dass dies eine sehr eingeschränkte Definition von OOP ist, die so keineswegs allgemein gültig ist. Es gibt Konzepte, die OOP ganz ohne Vererbung fassen, anders als die von Sun/Java. Ich fände es ja zielführender, hier nicht immer nur auf dieser einen (einseitigen) Begriffsdefinition zu beharren.

Gruß

jobo

[Struppi]

Warum das so ist, ist eine Grundlage der OOP. Wenn du nicht OO programmierst, brauchst du vielleicht keine Kapselung.

@Struppi: Du weißt doch, dass dies eine sehr eingeschränkte Definition von OOP ist, die so keineswegs allgemein gültig ist. Es gibt Konzepte, die OOP ganz ohne Vererbung fassen, ...

Wer hast denn jetzt plötzlich von Vererbung gesprochen?
Ich nicht.

Und wenn du Kapselung als einschränkend empfindest, ist das auch kein Problem. Ich habe bereits mehrfach in diesem Thread erwähnt, dass es auch möglich ist mit Sprachen OO zu programmieren, die dafür nicht entwickelt wurden. Ich wollte lediglich zeigen, welche OO Paradigmen im JS Sprachkern nur schwach bzw. gar nicht umgesetzt sind.

Struppi.

[jobo]

Hallo,

Warum das so ist, ist eine Grundlage der OOP. Wenn du nicht OO programmierst, brauchst du vielleicht keine Kapselung.

@Struppi: Du weißt doch, dass dies eine sehr eingeschränkte Definition von OOP ist, die so keineswegs allgemein gültig ist. Es gibt Konzepte, die OOP ganz ohne Vererbung fassen, ...

Wer hast denn jetzt plötzlich von Vererbung gesprochen?

Naja, wenn es um "protected" geht, dann ist das m.E. eine Variable, die vererbbar privat ist. Also wenn ich nicht von protected rede, dann ist privat, wie andere es ja auch sehen, bei JS ident mit dem, was PHP als private anbietet. Die Kapselung wird durchs Closure geboten und ich habe durch previlegierte Funktionen zugriff darauf. Nicht direkt ansprechbar, nur durch public methods. Die Kapselung ist doch aber kein Begriff, der für OOP steht. Bzw. findet sich das doch (Closures) bei Funktionen und ggfs. "funktionaler Programmierung" genau so, hätte ich jetzt gemeint.

Gruß

jobo

[Struppi]

Aber das geht:

function MyClass(){

var private;
}

MyClass.prototype.myFunction = function() {
alert(this.private);
};

  
Nein, das geht nicht.  
  

> Es ist doch klar, dass bei  
> > function() { alert(private); }  
> die JS-Engine nicht wissen kann, was denn nun "private" überhaupt sein soll.  
  
Genau darum ging es, dass JS keine Klassenweite private Eigenschaften kennt.  
  
Struppi.

[molily]

Hallo,

Aber (tut mir Leid das ich jetzt auch noch mal auf
deinem Beispiel rumhacke molily) das war einfach mal das Paradebeispiel dafür warum ich die nativen Lösungen alle nicht allzu Prickelnd finde.

Es gibt keine »native Umsetzung«. Meine ist ebenso wenig wie deine »nativ«. Meine Helferfunktion macht exakt dasselbe wie du in der Zeile
_classConstructor.prototype = Object.create(_parentConstructor.prototype);

Ich muss ehrlicher weise zugeben das ich deinen Artikel noch nicht gelesen habe und somit deine inheritPseudoClass Funktion noch nicht kannte. Erst als ich mir die Implementierung agesehen habe wurde mir klar warum method4 nicht existiert.

Was soll das für ein Argument sein? APIs sind nicht selbsterklärend. Keine. Nicht jQuery, nicht PrototypeJS, nicht Mootools, nicht class.js. Wieso muss man bei class.js den Klassennamen als String übergeben, anstatt dass create sie zurückgibt? Wieso sind private, public, protected globale Variablen anstatt bspw. als Parameter in die Funktion gegeben zu werden? Das sind alles Entscheidungen für und gegen etwas. Sicher begründete, darum geht es nicht. Es sind einfach nicht triviale, nicht intuitive Entscheidungen, die man treffen muss.

Das Hauptproblem was ich bei nativen Umsetzung sehe ist, dass man Funktionen aufrufen muss nachdem man seine eigentliche Klassendefinition geschrieben hat, um die Logik seiner Klasse zu Komplettisieren.

Wie gesagt ist mir dieses Problem bekannt, aber relativ einfach lösbar. Es war schlicht nicht Anliegen des Artikels. Dort sollte nur dieses Pattern vorgestellt werden, welches sich so in fast allen Pseudoklassen-Implementationen findet.

Ich frage mich, was ihr alle habt. Bitte lest doch erst meinen Artikel und meine Postings hier. Ich habe nicht den Anspruch, mit einer zweizeiligen (!) Helfer-Funktion mit 200-zeiligen Klassenframeworks zu konkurrieren. Wie ich schon sagte, meine Lösung bietet wenig Komfort und wenig Flexibilität, sondern soll eine Kernaufgabe in eine Helferfunktion verlagern.

Es ist mehr eine Erklärung der internen Funktionsweise und der Hintergründe als eine robuste und in jedem Fall gebrauchstaugliche Lösung. Es ist gut, deren Beschränkungen aufzuzeigen (was mein Artikel auch bereits ansatzweise leisten soll), doch es bringt nichts, sie mit ausgereifteren Lösungen zu vergleichen.

So muss man beispielsweise den prototypen seine Klasse nachträglich setzen, oder sich irgendwo Methoden zwischen merken wenn man sie kurz darauf Überschreiben will, aber diese dennoch aufrufen will (super call).

Wie gesagt, wenn man den bestehenden Prototyp erhalten will und die Member in den neuen herüberretten will, kann man das mit ein paar Zeilen umsetzen.

Prototyping ist genial wenn man Funktionalitäten von Bibliotheken oder bestehenden Klassen erweitern will, aber sein Gundlogik so aufzubauen und zusammen zu halten ist jedoch sehr umständlich mit Prototyping.

Was meinst du mit Prototyping? Arbeitest du nicht mit prototypischer Vererbung?

Jetzt zu den bestehenden Frameworks. Ja durchaus gibt es ein Reihe von Frameworks mit den man ebenfalls seine Klassendefinitionen strukturiert verfassen kann. Aber auch hier habe ich noch keine Variante gefunden bei der man auf dem ersten Blick sieht wo was angegeben und deklariert wird.

Es gibt keine und wird auch keine geben. Wenn es die eine »richtige« Lösung gäbe, dann frage ich mich, warum sich sämtliche Pseudoklassen-Umsetzungen stark in der API unterscheiden.

var Chicken = Y.extend(...);
Wer mir hier auf Anhieb sagen kann was hier was zu bedeuten hat, verdient meinen Respekt.

Du verstehst ein Framework ganz alleine dadurch, dass du den Code liest, der die API nutzt? Du erkennst die Bedeutung von Parametern ganz intuitiv? Das halte ich für unmöglich. Sicher kann man eine API mehr oder weniger intuitiv gestalten. Die mir bekannten Pseudoklassen-APIs sind dazu jedoch zu komplex, als dass das alles selbsterklärend wäre.

Aber der kann mir sicherlich auch erklären warum die Argumentreihenfolge gerade Konstruktor, Elternkonstruktor und dann Members ist.

Ganz einfach: Sie ist willkürlich. So willkürlich wie Mootools alle Daten in einem Hash erwartet, so willkürlich wie PrototypeJS den Parent-Konstruktor bei Class.create als ersten Parameter entgegennimmt oder nur einen Hash-Parameter, wenn keine Superklasse existiert. Da sind alles für sich gesehen stimmige Entscheidungen - im Kontext des jeweiligen Frameworks und deren Paradigmen.

Nun über sein eigens Werk zu Urteilen ist immer schwer, aber wem schon einmal Klassen in einer typischen OO Programmiersprache über den Weg gelaufen sind, ...

Das ist, wie ich schon versucht habe darzulegen, eine problematische Überlegung, wenn es um JavaScript geht. Ich will dich nicht demotivieren, mache dein Framework ruhig breiter bekannt. Du wirst aber auch auf harsche Kritik von eingefleischten JavaScriptern stoßen. Leute, die JavaScript bewusst als JavaScript und nicht als Java programmieren und es für sinnvoll halten, dass Neueinsteiger JavaScript als solches lernen anstatt entscheidenden Sprachfeatures wegzukapseln. Leute, die durchaus kommerzielle JavaScript-Projekte mit zehntausenden Zeilen Code entwickeln und Frameworks einsetzen, die sehr strenge Strukturen vorgeben.

Neben Dojo und Ext JS ist YUI immer noch eins der größten und ausgereiftesten UI-Frameworks, an dem dutzende Entwickler parallel arbeiten. Es ist sicher nicht die Argumentreihenfolge von Y.extend, die für Erfolg oder Misserfolg verantwortlich ist. Wie gesagt bleibt YUI da vergleichsweise low-level, trotzdem benutzen m.W. sämtliche YUI-Module diese Struktur.

Hm hier schieden sich wohl die Geister warum muss der Programmierer sich selbst Strukturen schaffen?

Wenn das jeder tun würde und man mit mehreren Leuten an einem Projekt arbeitet, was gibt denn das für ein Wust...

Richtig, dafür gibt es Frameworks, die »Convention over Configuration« stellen. Dagegen habe ich nichts, im Gegenteil. Es gibt eben nur verschiedene mögliche Konventionen im Bereich Metaprogramming und Domain-specific Languages. Alle haben ihre Vorzüge und Anwendungsfälle. »Generisch« gibt es nicht, es ist immer eine bewusste Entscheidung für eine bestimmte Art, Probleme in Code auszudrücken, und damit gegen eine andere. Es gibt nicht umsonst neben statischen klassenbasierten Programmiersprachen viele andere. Diese sind nicht zwangsläufig chaotisch oder konventionslos und sollten deshalb in ein Klassenkorsett gezwängt werden, um sie brauchbar zu machen. Was Neueinsteiger angeht, so kann man sich nur auf eine Gruppe mit einem bestimmten Hintergrund kaprizieren, wie es dein Framework auch tut.

Mathias

[jobo]

Hallo,

Wer sie einsetzt, sollte verstehen, was sie macht. Andernfalls sollte man eine ausgereifte Lösung wie in Mootools oder PrototypeJS einsetzen. Da sieht man nichts von Konstruktoren und Prototypen, sondern ruft bloß eine Methode auf und übergibt ein Object mit sämtlichen Membern. Diese Schreibweise ist idiotensicher, allerdings ist die interne Funktionsweise völlig weggekapselt.

Wieso "allerdings". Ist das als "nachteilig" gemeint? Oder als "dabei" bzw.  "weil"?

Durch die Lektüre welches Frameworks lässt sich denn diese Prinzip am besten nachvollziehen? "CoffeeScript" (das erwähnt ja auch Crockford positiv in einem seiner Vorträge Ende 2010) oder MooTools oder Prototype oder lieber YUI? Oder mehrere davon, damit man sieht, worums im Kern geht?

Gruß

jobo

[molily]

Durch die Lektüre welches Frameworks lässt sich denn diese Prinzip am besten nachvollziehen?

Keines. Am ehesten noch YUI.

"CoffeeScript" (das erwähnt ja auch Crockford positiv in einem seiner Vorträge Ende 2010) oder MooTools oder Prototype oder lieber YUI? Oder mehrere davon, damit man sieht, worums im Kern geht?

CoffeeScript ist eine Metasprache, die nach ECMAScript kompiliert. CoffeeScript erlaubt Klassendeklarationen, welche direkt in Low-Level-Code mit Konstruktor und Prototyp umgesetzt werden. Vererbung wird wie in meiner Helferfunktion umgesetzt, Super-Aufrufe werden zu Konstruktor.superkonstruktor.prototype.call(this, ...) umgeschrieben. Von den Interna sieht man also nichts. Das entstehende JavaScript hingegen ist total straight und Low-Level. Ist es einmal nach JavaScript kompiliert, ist darin nur sehr wenig Metaprogramming nötig (eigentlich nur die __extends-Helferfunktion).

Mootools erlaubt mit new Class({...}) das Deklarieren von Klassen als Object-Literal. Superklassen gibt man mit einer Extends-Property an, eine Art Konstruktorfunktion als initialize-Property (es ist letztlich nicht der wirkliche Konstruktor). Mootools wrappt sämtliche Methoden, um this.parent()-Calls zu ermöglichen.

PrototypeJS erlaubt mit Class.create(Superclass, {...}) etwas ähnliches. Es wrappt alle Methoden, welche $super als Parameter entgegen nehmen, und gibt die Super-Methode darüber in die Methode hinein.

YUI habe ich anderswo ausführlich beschrieben. YUI bietet mehr einen Satz von losen Helferfunktionen sowie Module anstelle eines abgeschlossenen Klassenkonzepts. Wrapping wird dort nur gemacht, um Module vor der Benutzung seiner Methoden zu initialisieren, ansonsten ist es relativ Low-Level. Es gibt z.B. keinen syntactic sugar für Super-Calls. Dass mit intern Konstruktoren und Prototypen gearbeitet wird, liegt bei YUI noch ziemlich an der Oberfläche.

Mathias

[molily]

Diese Schreibweise ist idiotensicher, allerdings ist die interne Funktionsweise völlig weggekapselt.

Wieso "allerdings". Ist das als "nachteilig" gemeint? Oder als "dabei" bzw.  "weil"?

Beides. Wie gesagt erlaubt diese Schreibweise keine Mehrdeutigkeiten und mehrere Schritte werden in einem zusammengefasst, sodass ihre Reihenfolge keine Rolle spielt. Gleichzeitig sehe ich es als negativ an, Programmierern vorzugaukeln, das sei echte klassenbasierte OOP. Das ist eine Leaky Abstraction. Man kann die Natur der Sprache nur bedingt verstecken.

Man wird sehr schnell zu dem Punkt kommen, wo diese Abstraktion nicht funktioniert. Beispielsweise beim Verwenden von Methoden als Funktionsobjekte (addEventListener, setTimeout, forEach). Dann benötigt man Function Binding bzw. Closures. Was hat das mit Klassen zu tun? Nichts, es ist funktionale Programmierung. Funktionen sind Objekte erster Klasse und »this« hat erst einmal gar nichts mit Pseudoklassen zu tun. Die klassenbasierte Sprache ActionScript 3 löst das, indem sie Klassenmethoden automatisch bindet, wenn diese funktional verwendet werden. Das tut JavaScript eben nicht. Man kann das für den Programmierer auch nur minimal vereinfachen. Für alle Methoden den Kontext zu erzwingen, würde wieder andere Probleme mit sich bringen.

Mathias

[jobo]

Hallo,

Für alle Methoden den Kontext zu erzwingen, würde wieder andere Probleme mit sich bringen.

Ich finde ja intuitiv, dass "this" doch bei Javascript eine durchgängige Logik hat. Warum soll "this" denn nicht der Button sein, wenn sein onclick = meineFunktion; ist? Ich häng den button ja nicht nicht an mein Objekt sondern hänge eine Funktion/Objekt an den Button. So ist setTimeout/Intervall ja auch eine Funktion, die an dieses _window_(!).Event gehangen wird. Also auch logisch, das "this" dann das Objekt meint, an das die Funktion gehangen wurde.

Ich dachte jetzt, das "this"-"Problem" sei gelöst, wenn ich allen Buttons zB. eine einzige onclick-Funktion zuweise, die zB. (das ist jetzt unschön aber fürs paradigamtische ja vielleicht doch sinnvoll) das this.innerHTML als Anhaltspunkt nimmt, die entsprechende Funktion (m)eines ActionObjektes aufzurufen. Diese Routing-Funktion kann ja auch den eventfeuernden Button als Parameter mit übergeben, wenn das sinnvoll erscheint.

Sinngemäß:

  
(function () {  
    var myActionController, myRouter;  
    myActionController = {  
        someButtonName : function (button) {  
            /*globals alert*/  
            alert(button.innerHTML);  
        }  
    };  
    myRouter = function () {  
        // this ist der button der geklickt wurde  
        var action = this.innerHTML;  
        if (myActionController.hasOwnProperty(action)) {  
            myActionController.action(this);  
        }  
    };  
    document.getElementsByTagName("button").onclick = myRouter;  
}());  

Weiß nicht, ob das einem der Pattern entspricht, die Du in einem Deiner Artikel beschrieben hast. Die las ich grad weiter quer bzw. durch und wollte das noch fortsetzen.

Gruß

jobo