nicht angemeldet molily
molily
molily
molily
molily
molily
Hi Leute,
eine Frage: Kann mir jemand erklären, wie ich die Variable aus der Funktion "auslesen" rüber bekomme in die Funktion "erstellen"? So wie ich es jetzt habe, klappt es nicht.
Auge
Matthias Apselfunction auslesen() {
var y =15;
}
function erstellen(){
x = auslesen.y;
}
Danke im Voraus!
Mfg
hi chris1234,
eine Frage: Kann mir jemand erklären, wie ich die Variable aus der Funktion "auslesen" rüber bekomme in die Funktion "erstellen"? So wie ich es jetzt habe, klappt es nicht.
function auslesen() {
var y =15;}function erstellen(){
x = auslesen.y;}
Funktionen haben einen Scope und nur wenn du sie mit "new" versiehst, kriegst Du eine Objekt. Aber das ist u.U. garnicht sinnvoll. Die Frage sollte eher sein, warum du das so machen willst.
mfg
tami
Funktionen haben einen Scope und nur wenn du sie mit "new" versiehst, kriegst Du eine Objekt.
Erhalte ich mit return { foo: "bar" }; etwa kein Objekt?
\0
hi Martin,
Funktionen haben einen Scope und nur wenn du sie mit "new" versiehst, kriegst Du eine Objekt.
Erhalte ich mit
return { foo: "bar" };etwa kein Objekt?
Nun, wenn du ein Objekt zurück gibst, natürlich. Das ist aber keine "Eigenschaft" der Funktion. S.a. https://forum.selfhtml.org/?t=217834&m=1497664
mfg
tami
Funktionen haben einen Scope und nur wenn du sie mit "new" versiehst, kriegst Du eine Objekt.
Erhalte ich mitreturn { foo: "bar" };etwa kein Objekt?
Nun, wenn du ein Objekt zurück gibst, natürlich. Das ist aber keine "Eigenschaft" der Funktion. S.a. https://forum.selfhtml.org/?t=217834&m=1497664
Im return-Statement habe ich aber auf die Eigenschaften der Funktion vollen Zugriff.
function iam(nickname) {
this.name = nickname;
var dat = this;
return {
ami: function() { console.log(dat.name); }
};
}
var who = iam("tami");
who.ami(); // => "tami"
\0
Im return-Statement habe ich aber auf die Eigenschaften der Funktion vollen Zugriff.
function iam(nickname) {
this.name = nickname;var dat = this;
return {
ami: function() { console.log(dat.name); }
};
}var who = iam("tami");
who.ami(); // => "tami"
Und wo greifst du hier auf die Eigenschaften einer Funktion zu? Ich sehe es nirgends.
Welcher Funktion überhaupt? Ich sehe da nur zwei Funktionen, iam und eine anonyme, die in einer Eigenschaft ami gespeichert wird. iam rufst du ohne »new« auf, sodass »this« darin auf das globale Objekt window zeigt bzw. undefined im ECMAScript 5 Strict-Mode. Ich vermute, du missverstehst die Funktionsweise von »this«. »this« ist nicht das aktuelle Funktionsobjekt, das wäre [arguments.callee](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/arguments/callee) (existiert nur im Nicht-Strict-Mode). Mit obigen Beispiel hast du erfolgreich die Eigenschaft name des globalen Objekts beschrieben, siehe <http://de.selfhtml.org/javascript/objekte/window.htm#name@title=window.name>.
Wie auch immer, ich verstehe ohnehin nicht, worum es in diesem Zweig geht.
Mathias
Ich vermute, du missverstehst die Funktionsweise von »this«.
Ja, das stimmt.
»this« ist nicht das aktuelle Funktionsobjekt
Davon bin ich ausgegangen. ;)
Wie auch immer, ich verstehe ohnehin nicht, worum es in diesem Zweig geht.
Mich hat er zumindest ein Stückchen weiter gebracht!
\0
Hallo,
Kann mir jemand erklären, wie ich die Variable aus der Funktion "auslesen" rüber bekomme in die Funktion "erstellen"?
Werte lassen sich über Parameter an Funktionen übergeben. Dazu rufst du eine Funktion auf und notierst die Werte zwischen den Klammern des Funktionsaufrufs. Die Funktion nimmt Parameter entgegen, indem in der Parameterliste Variablennamen notiert werden.
function ausgabe(text) {
alert(text);
}
ausgabe("Mein Name ist Hase");
Siehe:
http://de.selfhtml.org/javascript/sprache/funktionen.htm
http://www.mediaevent.de/javascript/Javascript-Funktionen-Grundlagen.html
https://developer.mozilla.org/de/docs/JavaScript/Guide/Funktionen
http://www.html-world.de/246/funktionen-3/
Mathias
Hello,
eine Frage: Kann mir jemand erklären, wie ich die Variable aus der Funktion "auslesen" rüber bekomme in die Funktion "erstellen"? So wie ich es jetzt habe, klappt es nicht.
Funktionen haben üblicherweise Rückgabewerte.
JavaScript arbeitet aber objektorientiert, so dass Du auch Methoden einer Klasse daraus machen könntest. Diese können dann auf gemeinsame Eigenschaften der Klasse zugreifen.
function auslesen()
{
var y =15;
return y;
}
function erstellen(x)
{
return 'Der Wert lautet ' + x ;
}
alert(erstellen(auslesen()));
Du musst dich nur entscheiden, welchen Stil Du benutzen willst. Für JavaScript wäre objektorientiert mMn schlüssiger.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
eine Frage: Kann mir jemand erklären, wie ich die Variable aus der Funktion "auslesen" rüber bekomme in die Funktion "erstellen"? So wie ich es jetzt habe, klappt es nicht.
Funktionen haben üblicherweise Rückgabewerte.
JavaScript arbeitet aber objektorientiert, so dass Du auch Methoden einer Klasse daraus machen könntest. Diese können dann auf gemeinsame Eigenschaften der Klasse zugreifen.
function auslesen()
{
var y =15;
return y;
}function erstellen(x)
{
return 'Der Wert lautet ' + x ;
}alert(erstellen(auslesen()));
Du musst dich nur entscheiden, welchen Stil Du benutzen willst. Für JavaScript wäre objektorientiert mMn schlüssiger.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Danke Tom, hat jetzt geklappt!
Hi Leute,
eine Frage: Kann mir jemand erklären, wie ich die Variable aus der Funktion "auslesen" rüber bekomme in die Funktion "erstellen"? So wie ich es jetzt habe, klappt es nicht.
Du könntest die Variable als Eigenschaft Deiner Funktion deklarieren.
Horst
Hello Hotti,
eine Frage: Kann mir jemand erklären, wie ich die Variable aus der Funktion "auslesen" rüber bekomme in die Funktion "erstellen"? So wie ich es jetzt habe, klappt es nicht.
Du könntest die Variable als Eigenschaft Deiner Funktion deklarieren.
<p mode="noergel">
Ich würde dann eher sagen:
Aber eine Funktion hat keine Eigenschaften, nur (private) Variablen
Und eine wenn es Eigenschaften sind, dann gehören die der Klasse
</p>
@all
Ich bitte darum, mich zu berichtigen/vervollständigen
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
hi Tom,
Hello Hotti,
eine Frage: Kann mir jemand erklären, wie ich die Variable aus der Funktion "auslesen" rüber bekomme in die Funktion "erstellen"? So wie ich es jetzt habe, klappt es nicht.
Du könntest die Variable als Eigenschaft Deiner Funktion deklarieren.
<p mode="noergel">
Ich würde dann eher sagen:
- als Eigenschaft der Klasse, deren Methoden "auslesen()" und "erstellen()" sind.
- als Funktionsargument und Rückgabewert (so wie ich es gezeigt habe
Aber eine Funktion hat keine Eigenschaften, nur (private) Variablen
Und eine wenn es Eigenschaften sind, dann gehören die der Klasse</p>
@all
Ich bitte darum, mich zu berichtigen/vervollständigen
http://molily.de/js/objekte-variablen.html
Funktionen haben keine Eigenschaften. Funktionen können aber <http://de.selfhtml.org/javascript/sprache/objekte.htm#eigene@title=Objekte erzeugen mit "new">.
mfg
tami
Funktionen haben keine Eigenschaften.
dann verstehe ich das hier:
http://de.selfhtml.org/javascript/objekte/function.htm
irgendwie falsch.
hi tinita,
Funktionen haben keine Eigenschaften.
dann verstehe ich das hier:
http://de.selfhtml.org/javascript/objekte/function.htm
irgendwie falsch.
das kann sein.
mfg
tami
hi tami,
Funktionen haben keine Eigenschaften.
dann verstehe ich das hier:
http://de.selfhtml.org/javascript/objekte/function.htm
irgendwie falsch.das kann sein.
<script>
[code lang=javascript]function Test() {
"use strict";
var a = "b";
alert("a aus test:" + a);
this.b = "b";
}
var test2 = Test;
alert(test2.a); //nix
alert(typeof test2.a); //undefined
alert(test2.b); //nix
alert(typeof test2.b); //undefined
var Test3 = new Test(); // a aus test: b
alert(Test3.a); //nix
alert(typeof Test3.a); //undefined
alert(Test3.b); // b
</script>
[/code]»»
mfg
tami
Funktionen können natürlich auch selbst definierte Eigenschaften haben.
function Test(a) {
this.b = function() {
this.constructor.staticC = a;
};
}
var test1 = new Test("test1");
var test2 = new Test("test2");
test2.b();
alert(Test.staticC);
test1.b();
alert(Test.staticC);
hi unknown,
Funktionen können natürlich auch selbst definierte Eigenschaften haben.
function Test(a) {
this.b = function() {
this.constructor.staticC = a;
};
}
var test1 = new Test("test1");
var test2 = new Test("test2");
test2.b();
alert(Test.staticC);
test1.b();
alert(Test.staticC);
naja, ohne "new" kommst du da aber nicht ran.
~~~javascript
function Test(a) {
this.b = function() {
this.constructor.staticC = a + "abc";
};
}
//~ var test1 = new Test("test1");
//~ var test2 = new Test("test2");
//~ test2.b();
//~ alert(Test.staticC);
//~ test1.b();
alert(Test.staticC); //nix
alert(typeof Test.staticC); // undefined
mfg
tami
function Test() {
}
Test.a = "doch";
alert(Test.a);
hi unknown,
function Test() {
}
Test.a = "doch";
alert(Test.a);
Ich kann denn Unterschied, den ich zu PHP (und vermutlich Java) mit seinen Properties/Eigenschaften und Methods/Methoden nicht so recht in Worte fassen, den ich sehe:
~~~javascript
function Test(a) {
this.b = function() {
this.constructor.staticC = a + "abc";
};
}
//~ var test1 = new Test("test1");
//~ var test2 = new Test("test2");
//~ test2.b();
//~ alert(Test.staticC);
//~ test1.b();
alert(Test.staticC);
alert(typeof Test.staticC); // undefined
Function.prototype.a = "doch";
alert(Test.a); //doch
Es macht doch nicht viel Sinn, einer Funktion eine Eigenschaft zuzuweisen, oder? Auch wenn sie ein Objekt ist, dass von Function.prototype erbt. Zumindest ist es doch logisch was anderes, wenn ich mit myObj = {"a":"doch"}; ein Objekt erzeuge mit der Eigenschaft a (und noch Methoden, wenn ich das will).
mfg
tami
Ich kann denn Unterschied, den ich zu PHP (und vermutlich Java) mit seinen Properties/Eigenschaften und Methods/Methoden nicht so recht in Worte fassen, den ich sehe:
Ich kann nicht erkennen, worauf du hinaus willst.
function Test(a) {
this.b = function() {
this.constructor.staticC = a + "abc";
};
}
//~ var test1 = new Test("test1");
//~ var test2 = new Test("test2");
//~ test2.b();
//~ alert(Test.staticC);
//~ test1.b();
alert(Test.staticC);
alert(typeof Test.staticC); // undefined
Function.prototype.a = "doch";
alert(Test.a); //doch
Auch hier nicht.
Das Beispiel war von mir nur gewählt, um
1) zu zeigen, dass Funktionen Eigenschaften haben können
2) zu demonstrieren, daß sich damit etwas wie statische Variablen realisieren lassen.
~~~javascript
function Test() {
this.getStatic = function() {
return this.constructor.staticC;
};
};
Test.staticC = "abc";
var test1 = new Test();
alert(test1.getStatic());
das würde allen Funktionen die Eigenschaft geben
z.B. bind in alten Browsern verfügbar machen
if (!Function.prototype.bind) {
Function.prototype.bind = function (obj) {
...
};
}
hi unknown,
Ich kann nicht erkennen, worauf du hinaus willst.
Garnirgendwo. Ich dachte, es ginge hier ums Verständnis von Objekten, Methoden und Eigenschaften in Javascript. Eine Funktion hat von Hause aus Eigenschaften bzw. die Möglichkeit, welche zu haben, weil sie vom Objekt der Variante "Function" erbt. Functions bringen sechs (?) Eigenschaften von sich aus mit (s.a. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function): arguments, caller, displayName, length (Anzahl der erwarteten Argumente), name und prototype.
Warum ich die nicht mit for (i in Function) durchlaufen kann, kapiere ich grade nicht.
Ansonsten produziert:
Test = function () {
this.a = "b";
}
MyTest = new Test();
console.log(typeof Test); //function
console.log(typeof MyTest); //object
Wenn ich mit Daten arbeite, würde ich doch mit Objekten arbeiten, oder?
Test = function () {
this.a = "b";
}
Test.b = "c";
MyTest = new Test();
console.log(MyTest.b); // undefined
console.log(Test.b); // c
Aber was "habe" ich davon, dass meine Funktion Test noch die Eigenschaft b mit sich bringt, also fürs praktische Programmieren? Beim Currying&Co werden da noch Methoden rangepappt, das macht ja Sinn. Vermutlich aber erschließt sich mir hier irgendwas nicht bzw. finde ich nicht die passenden Beispiele im Netz dazu.
mfg
tami
Warum ich die nicht mit for (i in Function) durchlaufen kann, kapiere ich grade nicht.
Die sind wie die meisten js eigenen Eigenschaften mit "DontEnum" geflagt.
Aber was "habe" ich davon, dass meine Funktion Test noch die Eigenschaft b mit sich bringt, also fürs praktische Programmieren?
In der Regel nichts. Man kann, wie bereits gesagt, darüber soetwas wie statische Variablen emulieren.
hi unknown,
Warum ich die nicht mit for (i in Function) durchlaufen kann, kapiere ich grade nicht.
Die sind wie die meisten js eigenen Eigenschaften mit "DontEnum" geflagt.
Kann man das (aus Forschungsinteresse) umgehen?
Aber was "habe" ich davon, dass meine Funktion Test noch die Eigenschaft b mit sich bringt, also fürs praktische Programmieren?
In der Regel nichts. Man kann, wie bereits gesagt, darüber soetwas wie statische Variablen emulieren.
Und, tut "man" das? Gibt es Frameworks, die das nutzen?
mfg
tami
Kann man das (aus Forschungsinteresse) umgehen?
Nicht dass ich wüsste.
Ich habe mittlerweile auch verstanden, was du hiermit meintest:
Wenn ich mit Daten arbeite, würde ich doch mit Objekten arbeiten, oder?
In C++ erfolgen Außenzugriffe in der Regel über den Klassennamespace, genau wie die Variableninitialisierung.
Intern sehen Zugriffe auf statische Variablen aus wie Zugriffe auf normale Member, aber statische Variablen haben ja keinen eigentlichen Objektbezug.
http://www.learncpp.com/cpp-tutorial/812-static-member-functions/
hi unknown,
Kann man das (aus Forschungsinteresse) umgehen?
Nicht dass ich wüsste.Ich habe mittlerweile auch verstanden, was du hiermit meintest:
Wenn ich mit Daten arbeite, würde ich doch mit Objekten arbeiten, oder?
In C++ erfolgen Außenzugriffe in der Regel über den Klassennamespace, genau wie die Variableninitialisierung.
Intern sehen Zugriffe auf statische Variablen aus wie Zugriffe auf normale Member, aber statische Variablen haben ja keinen eigentlichen Objektbezug.
http://www.learncpp.com/cpp-tutorial/812-static-member-functions/
php ist auch so (MyClass::myMember/Property). myObject.myMember ja im grunde auch. nur dass javascript nicht "statisch" kennt, und nicht public/private/protected (zumindest nicht mit den keywords s.a. http://javascript.crockford.com/private.html
mfg
tami
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function
Warum ich die nicht mit for (i in Function) durchlaufen kann, kapiere ich grade nicht.
http://es5.github.io/ Suche nach [[Enumerable]]
http://es5.github.io/#x8.6.1
Testen mit:
$ Function.prototype.propertyIsEnumerable('bind')
false
$ Object.getOwnPropertyDescriptor(Function.prototype, 'bind')
Object {value: function, writable: true, enumerable: false, configurable: true}
Hier zeigt sich, dass die Eigenschaft nicht enumerable ist.
Test = function () {
this.a = "b";
}
MyTest = new Test();
console.log(typeof Test); //function
console.log(typeof MyTest); //object
Was daran liegt, dass der typeof-Operator ziemlich kaputt ist. Das sagt nicht aus, dass Funktionen keine Objekte sind… typeof gibt immer 'object' zurück, wenn es sich nicht um einen Primitive, eine Funktion oder undefined handelt.
> ~~~javascript
Test = function () {
> this.a = "b";
> }
> Test.b = "c";
> MyTest = new Test();
> console.log(MyTest.b); // undefined
> console.log(Test.b); // c
>
MyTest erbt natürlich nicht Eigenschaften ihres Konstruktors (Test), sondern nur die ihres Prototyps (Test.prototype).
var instanz = new Konstruktor();
// Eigene oder prototypisch vererbte Eigenschaft:
console.log(instanz.eigenschaft);
// Eigenschaft des Konstruktors, dasselbe wie Konstruktor.eigenschaft:
console.log(instanz.constructor.eigenschaft);
Aber was "habe" ich davon, dass meine Funktion Test noch die Eigenschaft b mit sich bringt, also fürs praktische Programmieren?
Solche »statischen Klassenmethoden« nutzt man in Javascript genauso wie in anderen Sprachen.
var User = function(attributes) {…};
User.from = function (json) {
var obj = JSON.parse(json);
return new User(obj);
};
Oder um Konstanten unterzubringen:
User.USER_ROLE = 0;
User.MODERATOR_ROLE = 1;
User.ADMIN_ROLE = 2;
(aus den Fingern gesaugt)
Mathias
hi molily,
Solche »statischen Klassenmethoden« nutzt man in Javascript genauso wie in anderen Sprachen.
var User = function(attributes) {…};
User.from = function (json) {
var obj = JSON.parse(json);
return new User(obj);
};
>
> Oder um Konstanten unterzubringen:
>
> ~~~javascript
User.USER_ROLE = 0;
> User.MODERATOR_ROLE = 1;
> User.ADMIN_ROLE = 2;
(aus den Fingern gesaugt)
"Aber" ich habe dann irgendwo
MyUser = new User(); ???
Bzw. warum lege ich nicht gleich ein User-Objekt an?
var User = {
"prop1":"abc",
"method1" : function () {
}
}
?
mfg
tami
"Aber" ich habe dann irgendwo
MyUser = new User();???
Ja, klar.
Bzw. warum lege ich nicht gleich ein User-Objekt an?
Weil ich dann einen Konstruktor habe *und* daran »statische« Eigenschaften/Methoden.
Klar, wenn ich das nicht brauche, dann reicht ein simples Objekt aus, dann brauche ich kein Funktionsobjekt mit allem Gedöns (Prototyp, Instanzen…).
Eine Konstruktorfunktion mit Eigenschaften wird meist verwendet, wenn man (pseudo-)klassenbasiert programmiert.
Metasprachen wie CoffeeScript »vererben« (kopieren) sogar statische Eigenschaften beim Vererben.
Mathias
hi molily,
"Aber" ich habe dann irgendwo
MyUser = new User();???Ja, klar.
Bzw. warum lege ich nicht gleich ein User-Objekt an?
Weil ich dann einen Konstruktor habe *und* daran »statische« Eigenschaften/Methoden.
Klar, wenn ich das nicht brauche, dann reicht ein simples Objekt aus, dann brauche ich kein Funktionsobjekt mit allem Gedöns (Prototyp, Instanzen…).
Eine Konstruktorfunktion mit Eigenschaften wird meist verwendet, wenn man (pseudo-)klassenbasiert programmiert.
Metasprachen wie CoffeeScript »vererben« (kopieren) sogar statische Eigenschaften beim Vererben.
Will jetzt keine Grundsatzdiskussion, "aber" dass Crockford meint, "new" wäre fehlerträchtig und könne seines Kenntnis standes immer umgangen werden, weißt du ja vermutlich. Keine Ahnung, ob "new" bei den von Dir verlinkten Libraries auftaucht, oder ob das "wirklich" "unnötig" ist.
mfg
tami
Meine Herren!
Will jetzt keine Grundsatzdiskussion, "aber" dass Crockford meint, "new" wäre fehlerträchtig und könne seines Kenntnis standes immer umgangen werden, weißt du ja vermutlich. Keine Ahnung, ob "new" bei den von Dir verlinkten Libraries auftaucht, oder ob das "wirklich" "unnötig" ist.
Wichtig ist es die Diskussion um das new-Keyword und native JavaScript-Konstruktoren zu vertehen und dann für den eigenen Anwendungsfall eine Abwägung vorzunehmen, ob ein Konstruktor oder eine Factory angebracht ist. Die Wahl pro "new" ist keinesfalls ein Indiz für schlechten Programmierstil. Dr. Axel Rauschmayer, den molily hier auch schon erwähnt hat, liefert zum Beispiel ein paar Argumente für Konstruktoren und gegen Factories.
hi 1UnitedPower,
Meine Herren!
Will jetzt keine Grundsatzdiskussion, "aber" dass Crockford meint, "new" wäre fehlerträchtig und könne seines Kenntnis standes immer umgangen werden, weißt du ja vermutlich. Keine Ahnung, ob "new" bei den von Dir verlinkten Libraries auftaucht, oder ob das "wirklich" "unnötig" ist.
Wichtig ist es die Diskussion um das new-Keyword und native JavaScript-Konstruktoren zu vertehen und dann für den eigenen Anwendungsfall eine Abwägung vorzunehmen, ob ein Konstruktor oder eine Factory angebracht ist. Die Wahl pro "new" ist keinesfalls ein Indiz für schlechten Programmierstil. Dr. Axel Rauschmayer, den molily hier auch schon erwähnt hat, liefert zum Beispiel ein paar Argumente für Konstruktoren und gegen Factories.
Da dann mal den Kommentar von Eric Elliot http://www.2ality.com/2013/07/defending-constructors.html#comment-977234354.
Zudem: "I believe the Crockford style of avoiding new at all costs comes mostly from protecting people who don't really know how to write JavaScript in projects at large.
This used to be good advice because pretty much no-one who built web applications really knew or liked JavaScript. In recent years we've seen a rise in complaints against the "avoid newing up objects" style."
Ich kapiere die wirklich ellenlange Diskussion nicht wirklich. Wenn "new" fehlerträchtig ist (oder auch nur sein kann, wenn der Kenntnisstand der Programmierer (=Mitarbeiter, zukünftiger Mitarbeiter, Nachfolger, sonstige) nicht ausreichend ist) und leicht umgangen werden kann, warum nicht? Eine Sorge weniger. Wenn das auch Douglas Crockford, Kyle Simpson und Eric Elliot so sehen ...;
mfg
tami
hi tami,
Will jetzt keine Grundsatzdiskussion, "aber" dass Crockford meint, "new" wäre fehlerträchtig und könne seines Kenntnis standes immer umgangen werden, weißt du ja vermutlich. Keine Ahnung, ob "new" bei den von Dir verlinkten Libraries auftaucht, oder ob das "wirklich" "unnötig" ist.
Wichtig ist es die Diskussion um das new-Keyword und native JavaScript-Konstruktoren zu vertehen und dann für den eigenen Anwendungsfall eine Abwägung vorzunehmen, ob ein Konstruktor oder eine Factory angebracht ist. Die Wahl pro "new" ist keinesfalls ein Indiz für schlechten Programmierstil. Dr. Axel Rauschmayer, den molily hier auch schon erwähnt hat, liefert zum Beispiel ein paar Argumente für Konstruktoren und gegen Factories.
Da dann mal den Kommentar von Eric Elliot http://www.2ality.com/2013/07/defending-constructors.html#comment-977234354.
Zudem: "I believe the Crockford style of avoiding
newat all costs comes mostly from protecting people who don't really know how to write JavaScript in projects at large.This used to be good advice because pretty much no-one who built web applications really knew or liked JavaScript. In recent years we've seen a rise in complaints against the "avoid newing up objects" style."
Ich kapiere die wirklich ellenlange Diskussion nicht wirklich. Wenn "new" fehlerträchtig ist (oder auch nur sein kann, wenn der Kenntnisstand der Programmierer (=Mitarbeiter, zukünftiger Mitarbeiter, Nachfolger, sonstige) nicht ausreichend ist) und leicht umgangen werden kann, warum nicht? Eine Sorge weniger. Wenn das auch Douglas Crockford, Kyle Simpson und Eric Elliot so sehen ...;
Und: "The issue for me is not about the non-safety or the inflexibility of constructors. The issue is more that constructors force the usage of two whole concepts new and this that the object-constructor pattern (and extending for inheritance) does not. Worse, these are two keywords that don't do what the vast majority of javascript developers think that they do.
Yes, it's a Crockford-style argument.
Admittedly, there are certainly advantages to using constructors - speed, memory, traceability, prototype inheritance. But, in building dozens of javascript-heavy SPAs I've seen a use case where these benefits actually matter maybe...once?
In the meantime I've had mountains of sessions with junior and even mid-level devs (which, let's be honest, in javascript world is most people) who can't figure out why the component they're trying to reuse won't work in their specific situation. It is almost always the fault of misunderstanding this. If the original developer had created a simple object rather than using constructors none of this would have been an issue.
For jQuery, underscore, any sort of reusable framework-building I perfectly understand, go ahead and use constructors. For applications other than the complicated in-browser SPAs? I can see your point. But in this specific but very popular use-case, how can you possibly justify that differential?
My own ranting blog post. Mostly against the use of this: https://github.com/togakangaroo/Blog/blob/master/javascript-on-this-and-new.md"
mfg
tami
Meine Herren!
Du wurdest in letzter Zeit schon öfter darauf aufmerksam gemacht. Ich weiß nicht, wieso du daraus nicht lernst. Du bist eigentlich ein angenehmer Diskussionpartner, aber solche zahllosen und ewigen Zitate nerven. Sie verwässern die Foren-Eigene-Diskussion. Jeder Mitleser dürfte inzwischen genug Stichworte aufgefasst haben, um sich tiefer in Thematik einlesen zu können, wenn es ihm beliebt, die musst du nicht alle ohne einen akuten Bezug servieren.
Und nein, ich möchte dir nicht den Mund verbieten, ich möchte dich nur nochmal dazu anhalten, deine Antwort-Moral etwas zu überdenken. Diese Frequenz derart winziger Informationshappen ist bei Twitter besser aufgehoben, da würde ich dir sogar folgen ;)
Meine Herren!
PS: Das sollte gar nicht so streng klingen. Die Schuld liegt nicht allein bei dir, diesem Forum fehlt auch die dringende Funktion Beiträge editieren zu können. Die fehlt aber leider, deswegen nur der Apell an dich, dass du die Informationen, die du mit uns teilen möchtest, erst mal selber sammelst und aggregierst und sie nicht einfach ungefiltert und unkommentiert an uns durchreichst. In diesen Fälle sehe ich nämlich wirklich keinen Mehrwert. Meine Lehrer haben früher übrigens immer gesagt "Was du nicht in eigenen Worten wiedergeben kannst, hast du nicht verstanden". Das möchte ich dir nicht unterstellen.
Hello,
PS: Das sollte gar nicht so streng klingen. Die Schuld liegt nicht allein bei dir, diesem Forum fehlt auch die dringende Funktion Beiträge editieren zu können.
Wie lange dürften die denn editierbar blieben? Bis eine Antwort gekommen ist?
Was mMn noch dringender fehlt, ist eine hauseigene Bilder/Grafik-Datenbank. Viele Beiträge sind nach Jahren theoretisch noch wichtig, aber praktisch nicht mehr brauchbar, da die verlinkten Bild-/Grafikressourcen inzwischen verschwunden sind.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Meine Herren!
PS: Das sollte gar nicht so streng klingen. Die Schuld liegt nicht allein bei dir, diesem Forum fehlt auch die dringende Funktion Beiträge editieren zu können.
Wie lange dürften die denn editierbar blieben? Bis eine Antwort gekommen ist?
Bis der Thread archiviert wird. Änderungen sollten sich transparent in einer Versionsgeschichte verfolgen lassen. Stackoverflow macht das ziemlich gut.
Hallo
Was mMn noch dringender fehlt, ist eine hauseigene Bilder/Grafik-Datenbank. Viele Beiträge sind nach Jahren theoretisch noch wichtig, aber praktisch nicht mehr brauchbar, da die verlinkten Bild-/Grafikressourcen inzwischen verschwunden sind.
Naja, das gilt aber genauso für Links zu irgendwelchen Seiten. Da landet auch so manches auf dem Müll oder kann nicht mehr verarbeitet werden, weil z.B. Parameter inzwischen anders heißen. Wo willst du da Halt machen?
Die paar Bilder, die ich hier im Laufe der Jahre eingefügt habe, sind immer noch erreichbar, weil ich sie selbst hoste und sie immer noch unter der selben URL verfügbar sind. Vielleicht sollte man sich allgemein daran gewöhnen, dass im Internet eben doch Manches verschwindet bzw. vergessen wird, ganz wie in der richtigen Welt.
Tschö, Auge
Om nah hoo pez nyeetz, Tom!
Was mMn noch dringender fehlt, ist eine hauseigene Bilder/Grafik-Datenbank. Viele Beiträge sind nach Jahren theoretisch noch wichtig, aber praktisch nicht mehr brauchbar, da die verlinkten Bild-/Grafikressourcen inzwischen verschwunden sind.
Das wird aber nicht passieren, wegen möglicher Urheberrechtsverletzungen.
Matthias
Moin Tom,
Was mMn noch dringender fehlt, ist eine hauseigene Bilder/Grafik-Datenbank. Viele Beiträge sind nach Jahren theoretisch noch wichtig, aber praktisch nicht mehr brauchbar, da die verlinkten Bild-/Grafikressourcen inzwischen verschwunden sind.
Diesen Gedanken hatten wir schon 2001. Das Problem hier ist ein rechtliches. Da könnte man sich ganz schnell eine Abmahnung einhandeln, weil wir uns damit urheberrechtlich geschütztes Material zu eigen machen könnten.
LG,
CK
Hello Christian,
Was mMn noch dringender fehlt, ist eine hauseigene Bilder/Grafik-Datenbank. Viele Beiträge sind nach Jahren theoretisch noch wichtig, aber praktisch nicht mehr brauchbar, da die verlinkten Bild-/Grafikressourcen inzwischen verschwunden sind.
Diesen Gedanken hatten wir schon 2001. Das Problem hier ist ein rechtliches. Da könnte man sich ganz schnell eine Abmahnung einhandeln, weil wir uns damit urheberrechtlich geschütztes Material zu eigen machen könnten.
Im Wiki passiert daoch aber nichts anderes. Da kann man auch Bilder bereitstellen für die Verständlichkeit des Geschriebenen...
Dann muss man die Upload-Möglichkeit für Bilder eben von einer ordentlichen Registrierung abhängig machen und den vermeintlichen Urheber (dessen Nick) beim Bild vermerken, inclusive direkter Kontaktmöglichkeit.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Moin Tom,
Im Wiki passiert daoch aber nichts anderes.
Jup, und die haben auch immer wieder Probleme damit. Nur ist die Wikipedia ein riesiges Projekt, die halt im Zweifel sagen können „nö, wir zahlen nicht. Verklag uns doch!” – SELFHTML kann das nicht.
LG,
CK
hi Tom,
Hello Christian,
Was mMn noch dringender fehlt, ist eine hauseigene Bilder/Grafik-Datenbank. Viele Beiträge sind nach Jahren theoretisch noch wichtig, aber praktisch nicht mehr brauchbar, da die verlinkten Bild-/Grafikressourcen inzwischen verschwunden sind.
Diesen Gedanken hatten wir schon 2001. Das Problem hier ist ein rechtliches. Da könnte man sich ganz schnell eine Abmahnung einhandeln, weil wir uns damit urheberrechtlich geschütztes Material zu eigen machen könnten.
Im Wiki passiert daoch aber nichts anderes. Da kann man auch Bilder bereitstellen für die Verständlichkeit des Geschriebenen...
Dann muss man die Upload-Möglichkeit für Bilder eben von einer ordentlichen Registrierung abhängig machen und den vermeintlichen Urheber (dessen Nick) beim Bild vermerken, inclusive direkter Kontaktmöglichkeit.
Nein. Du brauchst von jedem Urheber das Recht zur Veröffentlichung (copyright). Man braucht vom Fotografen also die Genehmigung in jedem Einzelfall, oder ein Fotograf gibt gleich eine Sammelgenehmigung. Ich vermute, dass man diese Rechte bei Wikipedia auch abgibt. [Nicht das Urheberrecht, das geht in D nicht, sondern das Veröffentlichungsrecht].
mfg
tami
hi 1UnitedPower,
ach weißt Du, wenn ich hier als Stammposter der Ansicht bin, dass das auch für Mitleser ein Gewinn sein könnte, bin ich mir grundsätzlich auch darüber im Klaren, dass da der ein oder andere vielleicht mal meinen könnte, ich sollte weniger von dem, was da schon stand mit im Posting lassen, oder nicht einfach nur einen kurzen Link "hinschmeißen". Ich bin da einfach anderer Ansicht. Und ja: wenn es eine editier-Funktion gäbe, hätte ich sie wohl genutzt. Und nein: nur weil einer die Dinge so auf den Punkt bringt, wie ich es gerne getan hätte, muss ich das nicht in meine eigenen Worte fassen. Und ja: u.U. habe ich noch nicht alles kapiert, aber das hier ist ja "work in progress".
Was ich mich frage ist, was reitet Dich, Matthias Apsel und "texter mit x" eigentlich? Ein klick, und du brauchst meinen Beitrag nicht zu lesen. Kannst ja auch den Link nehmen, und es Dir im Original angschauen. Und: "Texter mit x" hat mir Tofu "vorgeworfen", was Matthias Apsel aber so garnicht fand. Matthias fand meinen Link auf Rambda nicht so dolle (hat ihn "nicht gutgeheißen"), hier im Thread taucht aber zB. Lodash auf, worauf sich Ramda u.a. bezieht. Dir wiederum ist mein Zitat jetzt zu lang. Das wiederspricht aber eigentlich dem Kritikpunkt von Matthias und auch dem von Texter mit x.
Ich finde es keinen guten Stil, sich hier gegenseitig zu bemäkeln, weil einem dies oder jenes nicht passt. Schreibe jeder was und wie er will, wird ja sehen, ob er da Antworten bekommt oder nicht. Ich war bisher immer ganz zufrieden. Einziger Punkt hier: Forumscharta beachten. Aber das hat sich ja immens gebessert im Vergleich zu "damals".
mfg
tami
hi 1UnitedPower,
Meine Herren!
PS: Das sollte gar nicht so streng klingen. Die Schuld liegt nicht allein bei dir, diesem Forum fehlt auch die dringende Funktion Beiträge editieren zu können.
Im Archiv kommen die Postings schön vernestelt hintereinander weg. Editierfunktion nur damit dann im Archiv kein Balken dazwischen ist? Ich vermute einfach mal, wir können froh sein, dass das Forum von Christian hier funktioniert. Wer will denn hier eine Editierfunktion bauen? Das Forum ist ja leider irgendwie nicht irgendwo mal geforkt worden bzw. wird ja nicht von anderen Entwicklern irgendwie mit entwickelt, so dass man addons oder ähnliches hätte ...;
mfg
tami
hi 1UnitedPower,
Diese Frequenz derart winziger Informationshappen ist bei Twitter besser aufgehoben, da würde ich dir sogar folgen ;)
mfg
tami
Meine Herren!
Ich kapiere die wirklich ellenlange Diskussion nicht wirklich.
Kapierst du sie nicht, oder hast du dich schon für eine Position in der Debatte entschieden? Ich finde jedenfalls die Argumente auf beiden Seiten der Diksussion nachvollziehbar und schlüssig.
Wenn "new" fehlerträchtig ist (oder auch nur sein kann, wenn der Kenntnisstand der Programmierer (=Mitarbeiter, zukünftiger Mitarbeiter, Nachfolger, sonstige) nicht ausreichend ist) und leicht umgangen werden kann, warum nicht?
Das new-Keyword ganz zu vermeiden ist eine sehr rustikale Maßnahme, und es löst meiner Meinung weniger die Probleme mit Konstruktoren, als sie zu umschiffen. Factories kommen auch mit ihren eigenen Problemen, da ist es doch nachvollziehbar, dass auch andere Lösungsversuche diskutiert werden, findest du nicht?
Eine Sorge weniger. Wenn das auch Douglas Crockford, Kyle Simpson und Eric Elliot so sehen ...;
Nein, Crockford, Simpson und Elliot beteiligen sich bestimmt nicht an der Diskussion, um Vasallen zu gewinnen, die stumpf nach ihrer Pfeife tanzen. Sie wollen ja gerade, dass sich ihre Leser und Follower mit der Thematik beschäftigen und sie wollen gerade nicht, dass sich die Leser der Thematik verschließen.
hi 1UnitedPower,
Meine Herren!
Ich kapiere die wirklich ellenlange Diskussion nicht wirklich.
Kapierst du sie nicht, oder hast du dich schon für eine Position in der Debatte entschieden? Ich finde jedenfalls die Argumente auf beiden Seiten der Diksussion nachvollziehbar und schlüssig.
Ja, so sieht es aus. Da fragt man sich doch, wozu die Diskussion. Sich einfach "new" klemmen und gut ist. Die Vorteile erschließen sich mir im Verhältnis zur länge und Umfang des zu diskutierenden nicht.
Wenn "new" fehlerträchtig ist (oder auch nur sein kann, wenn der Kenntnisstand der Programmierer (=Mitarbeiter, zukünftiger Mitarbeiter, Nachfolger, sonstige) nicht ausreichend ist) und leicht umgangen werden kann, warum nicht?
Das new-Keyword ganz zu vermeiden ist eine sehr rustikale Maßnahme, und es löst meiner Meinung weniger die Probleme mit Konstruktoren, als sie zu umschiffen. Factories kommen auch mit ihren eigenen Problemen, da ist es doch nachvollziehbar, dass auch andere Lösungsversuche diskutiert werden, findest du nicht?
S.o. - nicht wirklich.
Eine Sorge weniger. Wenn das auch Douglas Crockford, Kyle Simpson und Eric Elliot so sehen ...;
Nein, Crockford, Simpson und Elliot beteiligen sich bestimmt nicht an der Diskussion, um Vasallen zu gewinnen, die stumpf nach ihrer Pfeife tanzen. Sie wollen ja gerade, dass sich ihre Leser und Follower mit der Thematik beschäftigen und sie wollen gerade nicht, dass sich die Leser der Thematik verschließen.
Elliot bleibt bei seinem Standpunkt. Das Zitat erspare ich mir jetzt mal.
mfg
tami
Hallo,
»new« ist nicht fehlerträchtig. Es tut das, was es soll, sehr gut. Es ist nur verwirrend und schwierig zu verstehen. Es sieht wie Java und klassenbasierte OOP aus, ist aber intern etwas anderes. Das ist ein bekannter Designfehler in JavaScript. Dasselbe gilt für »this«.
»new« macht nichts besonders, darunter stecken einfache Objekte, Konstruktoren und Prototypen. Wenn man das verstanden hat, kann man es sicher anwenden. Das tun tausende von Projekte auch.
Ich schreibe beruflich hauptsächlich Pseudoklassen in CoffeeScript, instantiiere sie mit »new« und arbeite mit CoffeeScripts Method-Binding. Das klappt hervorragend und ist gut lesbar. Ich wüsste nicht, was ich da alleine mit dem Verzicht auf »new« gewinnen würde. ECMAScript 6 wird »syntactic sugar« für Klassendeklarationen haben, die CoffeeScript und TypeScript sehr ähnlich sind. Das zeigt, dass diese Schreibweise weiter bleiben wird.
Korollar:
Weil »new« nur mit Wasser kocht,
… kann man *ohne* »new« *genau dasselbe* machen. Im Guten wie im Schlechten.
… haben andere Umsetzungen letztlich *dieselben* Probleme bei der Objektorientierung (z.B. mit »this«).
Ohne »new« kann man nichts Neues oder substantiell Anderes hinbekommen, man kann es höchstens weniger verwirrend notieren.
Ich halte die Standard-Schreibweise für ganz brauchbar, sehe keinen *zwingenden* Grund, sie zu wechseln. Sinnvoll wird das, wenn ich komplexere OOP umsetzen will. Man denke an so etwas wie JS.Class – was aber immer noch mit »new« arbeitet.
Mathias
hi molily,
Hallo,
»new« ist nicht fehlerträchtig. Es tut das, was es soll, sehr gut. Es ist nur verwirrend und schwierig zu verstehen.
Na, das mag ja der Punkt sein, den einige kluge Leute ja haben (s.a. https://forum.selfhtml.org/?t=217834&m=1497767).
Ich schreibe beruflich hauptsächlich Pseudoklassen in CoffeeScript, instantiiere sie mit »new« und arbeite mit CoffeeScripts Method-Binding. Das klappt hervorragend und ist gut lesbar. Ich wüsste nicht, was ich da alleine mit dem Verzicht auf »new« gewinnen würde. ECMAScript 6 wird »syntactic sugar« für Klassendeklarationen haben, die CoffeeScript und TypeScript sehr ähnlich sind. Das zeigt, dass diese Schreibweise weiter bleiben wird.
Naja, das erklärt doch Deinen Punkt. Crockford findet ja Coffee-Script auch interessant, meine ich mich zu erinnern.
Ich halte die Standard-Schreibweise für ganz brauchbar, sehe keinen *zwingenden* Grund, sie zu wechseln. Sinnvoll wird das, wenn ich komplexere OOP umsetzen will. Man denke an so etwas wie JS.Class – was aber immer noch mit »new« arbeitet.
Mir fehlt dazu die Erfahrung, ich muss mir wohl mal anschauen, wo "new" hier "was bringt" in JS, was man nicht andres umsetzen kann. Ich kenne es halt von PHP, aber da gehts ja garnicht ohne und es kann auch nicht zu Verwechslungen kommen, da eine Klasse nicht als Funktion genutzt werden kann.
mfg
tami
hi molily,
Ich halte die Standard-Schreibweise für ganz brauchbar, sehe keinen *zwingenden* Grund, sie zu wechseln. Sinnvoll wird das, wenn ich komplexere OOP umsetzen will.
https://molily.github.io/pottjs/#/38: "Alternatives: Don’t use new, just Object.create() and object factories" ???
mfg
tami
hi molily,
Hallo,
»new« ist nicht fehlerträchtig. Es tut das, was es soll, sehr gut. Es ist nur verwirrend und schwierig zu verstehen. Es sieht wie Java und klassenbasierte OOP aus, ist aber intern etwas anderes. Das ist ein bekannter Designfehler in JavaScript. Dasselbe gilt für »this«.
»new« macht nichts besonders, darunter stecken einfache Objekte, Konstruktoren und Prototypen. Wenn man das verstanden hat, kann man es sicher anwenden. Das tun tausende von Projekte auch.
Ich schreibe beruflich hauptsächlich Pseudoklassen in CoffeeScript, instantiiere sie mit »new« und arbeite mit CoffeeScripts Method-Binding. Das klappt hervorragend und ist gut lesbar. Ich wüsste nicht, was ich da alleine mit dem Verzicht auf »new« gewinnen würde. ECMAScript 6 wird »syntactic sugar« für Klassendeklarationen haben, die CoffeeScript und TypeScript sehr ähnlich sind. Das zeigt, dass diese Schreibweise weiter bleiben wird.
Da seh ichs ;-):
sam = new Snake("Sammy the Python");
tom = new Horse("Tommy the Palomino");
mfg
tami
hi tami,
hi molily,
Hallo,
»new« ist nicht fehlerträchtig. Es tut das, was es soll, sehr gut. Es ist nur verwirrend und schwierig zu verstehen. Es sieht wie Java und klassenbasierte OOP aus, ist aber intern etwas anderes. Das ist ein bekannter Designfehler in JavaScript. Dasselbe gilt für »this«.
»new« macht nichts besonders, darunter stecken einfache Objekte, Konstruktoren und Prototypen. Wenn man das verstanden hat, kann man es sicher anwenden. Das tun tausende von Projekte auch.
Ich schreibe beruflich hauptsächlich Pseudoklassen in CoffeeScript, instantiiere sie mit »new« und arbeite mit CoffeeScripts Method-Binding. Das klappt hervorragend und ist gut lesbar. Ich wüsste nicht, was ich da alleine mit dem Verzicht auf »new« gewinnen würde. ECMAScript 6 wird »syntactic sugar« für Klassendeklarationen haben, die CoffeeScript und TypeScript sehr ähnlich sind. Das zeigt, dass diese Schreibweise weiter bleiben wird.
Da seh ichs ;-):
sam = new Snake("Sammy the Python");
tom = new Horse("Tommy the Palomino");
Und da ich ja nicht editieren kann, kommt es noch hinten an:
<http://www.artandlogic.com/blog/tag/crockford/> - der Vergleich zwischen Coffee-Script und der "Crockford-Version" - darin u.a. [Zitat]: "Which One?
So which method is better? Because I’m more familiar with class-based inheritance, I’d rather just use CoffeeScript and ignore the underlying JavaScript implementation altogether. I like the fact that I can look at a CoffeeScript class definition and see on a single line both the name of the “class” and the name of the “class” it extends. In both JavaScript implementations, I have to search other lines to find the object that my object is extending. I find the use of the \_\_super\_\_ property a much more elegant solution when it comes to super methods. The functional method for accessing super methods would not scale well if there are a large number of super methods you want to access."
mfg
tami
»I like the fact that I can look at a CoffeeScript class definition and see on a single line both the name of the “class” and the name of the “class” it extends.«
Es ist ja immer dasselbe Problem: Es gibt eine Low-Level-Umsetzung, und das heißt in JavaScript: Objekte und Prototypenverweise. In einer Anwendung hingegen will ich eine High-Level-Abstraktion haben, die mir hilft, mein konkretes Problem kompakt und lesbar auszudrücken und zu lösen. Die mir ggf. die Interna versteckt, die mir gleichzeitig nicht die Möglichkeit nimmt, die Motorhaube aufzumachen und zu schrauben.
Das kann funktional sein, das kann pseudoklassisch sein, das kann Objektkomposition sein, das können Traits sein, das kann CoffeeScript, TypeScript oder ES6 Classes sein. Ich kann mir sehr fähige Objektsysteme in JavaScript bauen.
Ich verwende CoffeeScript-Klassen, weil es eine kompakte Syntax ist und doch überhaupt keine Magie beinhaltet, sondern stumpf zu einfachem JS kompiliert. Es schließt nicht aus, dass man mit den entstehenden Funktionen und Objekten noch Sperenzchen macht (z.B. Mixins).
Mathias
hi molily,
Ich verwende CoffeeScript-Klassen
Sowas wie einen "good-parts"-Generator. Minimiert ja vermutlich auch die Fehleranfälligkeit, und somit die Debuggingzeit. Und ist gut dokumentiert!
mfg
tami
hi tami,
Da seh ichs ;-):
sam = new Snake("Sammy the Python");
tom = new Horse("Tommy the Palomino");
>
> Und da ich ja nicht editieren kann, kommt es noch hinten an:
>
> [http://www.artandlogic.com/blog/tag/crockford/](http://www.artandlogic.com/blog/tag/crockford/) - der Vergleich zwischen Coffee-Script und der "Crockford-Version"
der Code am Ende vom Crockfordbeispiel funktioniert zwar, ist aber eigentlich "falsch". Es sollte/könnte heißen:
sam = Snake({name:'Sammy the Python'});
Es soll ja grade ein Beispiel ohne "new" sein, für rein Funktionale Vererbung.
mfg
tami
Hallo,
Du könntest die Variable als Eigenschaft Deiner Funktion deklarieren.
Ich würde dann eher sagen:
- als Eigenschaft der Klasse, deren Methoden "auslesen()" und "erstellen()" sind.
- als Funktionsargument und Rückgabewert (so wie ich es gezeigt habe
Aber eine Funktion hat keine Eigenschaften, nur (private) Variablen
Und eine wenn es Eigenschaften sind, dann gehören die der Klasse@all
Ich bitte darum, mich zu berichtigen/vervollständigen
Bitte macht euch erst einmal selbst schlau über das Objektsystem in JavaScript, bevor ihr etwas Unausgegorenes hinwerft, aus dem andere etwas Sinnvolles machen sollen.
In JavaScript gibt es keine Klassen, sondern Konstruktoren und Prototypen. Konstruktoren sind simple Funktionen, die mit dem new-Operator aufgerufen werden, und Prototypen sind beliebige Objekte.
Wenn ich einfach zwei globale Funktionen erzeuge, dann sind diese keine »Methoden einer Klasse«. Sie sind Methoden des Objektes window, sonst nichts. (Wenn sie Methoden einer *Klasse* wären, würden sie auch in anderen Window-Instanzen verfügbar sein, was nicht der Fall ist.)
Funktionen sind vollwertige Objekte, die den Konstruktor »Function« und den Prototype »Function.prototype« haben. Wie alle Objekte haben sie Eigenschaften und Methoden.
Die meisten Objekte sind veränderbar, es lassen sich also ad hoc neue Eigenschaften hinzufügen. Das gilt auch für Funktionen. Es gilt auch für den Prototypen Function.prototype, wenn *allen* Funktionen eine Eigenschaft/Methode hinzugefügt werden soll.
Die Möglichkeit, Eigenschaften hinzuzufügen, die nicht Methoden sind, wird selten genutzt.
http://molily.de/js/organisation-ueberblick.html#oop
http://molily.de/js/organisation-instanzen.html
https://molily.github.io/pottjs/
Alles das hat aber mit dem Ausgangsproblem dieses Threads eher wenig zu tun.
Mathias
Hello,
Bitte macht euch erst einmal selbst schlau über das Objektsystem in JavaScript,
Klar, gerne
In JavaScript gibt es keine Klassen, sondern Konstruktoren und Prototypen.
Und was sind Prototypen? Die hängen sicherlich vollkommen in der Luft?
Konstruktoren sind simple Funktionen, die mit dem new-Operator aufgerufen werden, und Prototypen sind beliebige Objekte.
Schön. Wie nennt man das sonst üblicherrweise, wenn es sich nicht um JavaScript handelt?
Wessen Objekt sind denn die "Objekte" in JS, wenn nicht einer Klasse? Dann wäre es doch vielleicht besser zu sagen, JavaScript ist eine Klasse, aber die lässt keine weiteren Ableitungen zu?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo,
Bitte macht euch erst einmal selbst schlau über das Objektsystem in JavaScript,
Klar, gerne
Scheint noch nicht passiert zu sein, du erwartest offenbar, dass ich es dir persönlich von Null an erkläre.
In JavaScript gibt es keine Klassen, sondern Konstruktoren und Prototypen.
Und was sind Prototypen? Die hängen sicherlich vollkommen in der Luft?
Wie gesagt, Prototypen sind Objekte. Wie die zustande kommen und wo die referenziert sind, ist völlig beliebig.
Die Prototypen der Kernobjekte sind erreichbar über [globales Objekt].Konstruktor.prototype. Im Browserkontext ist window das globale Objekt.
Siehe auch http://es5.github.io/#x15.
Konstruktoren sind simple Funktionen, die mit dem new-Operator aufgerufen werden, und Prototypen sind beliebige Objekte.
Schön. Wie nennt man das sonst üblicherrweise, wenn es sich nicht um JavaScript handelt?
Das soll wohl eine rhetorische Frage sein. Man sollte in JavaScript nicht mit dem Terminus »Klasse« hantieren, solange nicht klar ist, was gemeint ist (vgl. Pseudoklassen und ECMAScript-6-Klassendeklarationen). Diese Terminologie führt eher zu Verwirrung und Missverständnis.
Andere Sprachen haben feste, zur Laufzeit oftmals unveränderliche Typen, denen Exemplare/Instanzen gegenüber stehen. Nicht so in JavaScript. Da gibt es keine statischen Typdeklarationen, sondern Funktionen, die Objekte erzeugen, sowie prototypische Delegation zwischen Objekten. Man kann das volle OOP-Programm in JavaScript funktional und mit Prototypen durchziehen.
Wessen Objekt sind denn die "Objekte" in JS, wenn nicht einer Klasse?
Ich verstehe nicht, worauf du hinauswillst.
Objekte haben einen Konstruktor, der ist meist über die »constructor«-Eigenschaft zugänglich, und einen Prototyp-Verweis, der ist in der internen [[Prototype]]-Eigenschaft gespeichert und kann auch von außen in Erfahrung gebracht werden.
Einfache Objekte (z.B. ein Objekt-Literal {}) sind Instanzen des Konstruktors »Object« und haben den Prototyp »Object.prototype«, das ist der oberste Prototyp in den meisten Prototyp-Ketten.
Wenn ein Konstruktor ein Objekt erzeugt, spricht man zwar von einer »Instanz«, aber abgesehen von den (übrigens veränderlichen) constructor- und [[Prototype]]-Verweisen gibt es keine »magische« Typ-Exemplar-Verbindung.
(Primitives wie Number-Werte einmal ausgenommen, die haben eine inhärente Typzugehörigkeit.)
Dann wäre es doch vielleicht besser zu sagen, JavaScript ist eine Klasse, aber die lässt keine weiteren Ableitungen zu?
Häh? Natürlich erlaubt JavaScript Ableitungen. Bitte, lies dich ein bisschen ein.
Weiterer Lesestoff:
Mathias
hi molily,
Funktionen sind vollwertige Objekte, die den Konstruktor »Function« und den Prototype »Function.prototype« haben. Wie alle Objekte haben sie Eigenschaften und Methoden.
Die meisten Objekte sind veränderbar, es lassen sich also ad hoc neue Eigenschaften hinzufügen. Das gilt auch für Funktionen. Es gilt auch für den Prototypen Function.prototype, wenn *allen* Funktionen eine Eigenschaft/Methode hinzugefügt werden soll.
Und wie greife ich auf die Eigenschaft eine Funktion zu, wenn ich ohne "new" hantieren will?
in PHP $myClass->$myProperty; oder $myClass->myMethod();
Dieses Pendant in JS gibt es doch wohl nicht, es sei denn, ich hantiere mit new und der Funktion als Constructor, oder?
mfg
tami
Hallo,
wie greife ich auf die Eigenschaft eine Funktion zu
Wie bei allen Objekten, mithilfe des Property-Accessor-Operators:
objekt.eigenschaft
bzw.
objekt["eigenschaft"]
Angewandt auf eine Funktion:
var sum = function(a, b) { return a + b; };
alert(sum.length); // 2
sum.wtf = 'lol';
alert(sum.wtf); // lol
Mit »new« oder nicht »new« hat das erst einmal nichts zu tun.
Mathias
oder $myClass->myMethod();
Funktionen können natürlich auch Methoden haben, eingebaut sind u.a. apply, call und bind:
'use strict';
var f = function() { alert(this); }
f(); // undefined
f.call({ foo: 'bar' }); // [object Object]
f.apply({ foo: 'bar' }); // [object Object]
var f1 = f.bind({ foo: 'bar' });
f1(); // [object Object]
Das wird ständig in der objektorientierten wie der funktionalen JS-Programmierung verwendet (Stichworte: Method Binding, Currying/Partial Application, Higher-order Functions).
Siehe Bibliotheken, die Function.prototype erweitern:
http://api.prototypejs.org/language/Function/
http://sugarjs.com/api/Function
Und die Lodash-Funktionen für Funktionen:
http://lodash.com/docs (links zu »Functions« scrollen)
Siehe auch:
Function Binding
Function.prototype
apply
call
bind
Mathias
hi molily,
oder $myClass->myMethod();
Funktionen können natürlich auch Methoden haben, eingebaut sind u.a. apply, call und bind:
'use strict';
var f = function() { alert(this); }
f(); // undefinedf.call({ foo: 'bar' }); // [object Object]
f.apply({ foo: 'bar' }); // [object Object]var f1 = f.bind({ foo: 'bar' });
f1(); // [object Object]
>
> Das wird ständig in der objektorientierten wie der funktionalen JS-Programmierung verwendet (Stichworte: Method Binding, Currying/Partial Application, Higher-order Functions).
>
> Siehe Bibliotheken, die Function.prototype erweitern:
> [http://api.prototypejs.org/language/Function/](http://api.prototypejs.org/language/Function/)
> [http://sugarjs.com/api/Function](http://sugarjs.com/api/Function)
> Und die Lodash-Funktionen für Funktionen:
> [http://lodash.com/docs](http://lodash.com/docs) (links zu »Functions« scrollen)
>
> Siehe auch:
> [Function Binding](http://molily.de/js/organisation-verfuegbarkeit.html#binding)
> [Function.prototype](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/prototype)
> [apply](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/apply)
> [call](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/call)
> [bind](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind)
Das klingt gut (<https://forum.selfhtml.org/?t=217720&m=1496904>). Les ich morgen weiter. Über Currying und Funktionales Programmieren sprachen wir auch in der Computer-AG, die ist wieder morgen ;-).
Aber doch was anderes, als mit eigenen Objekten und Eigenschaften und vielleicht (wenn man das will) noch "dazugehörigen" Methoden zu hantieren <https://forum.selfhtml.org/?t=217834&m=1497710>.
mfg
tami