Textarea-Elemente erweitern

J. Strübig wrote:

Frank Seitz schrieb:
J. Strübig wrote:
Frank Seitz schrieb:

In OO-Sprechweise kann man HTMLTextAreaElement m.E. als
Klasse bezeichnen. Wie nennt man das sonst in JavaScript?

In JS gibt es nur Prototypen.

Das da oben (HTMLTextAreaElement) ist mit Sicherheit kein Prototyp.

Wer sagt das?

Ich (und sicherlich jeder, der mehr von JavaScript
versteht als ich).

Du kannst doch den prototypen sogar erweitern.

Ja, das habe ich ja selbst getan.
Der Prototyp ist nur nicht das Objekt HTMLTextAreaElement,
sondern das Objekt HTMLTextAreaElement.prototype.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Frank Seitz schrieb:

Der Prototyp ist nur nicht das Objekt HTMLTextAreaElement,
sondern das Objekt HTMLTextAreaElement.prototype.

Wenn das Objekt einen prototype hat, ist es auch ein Prototyp, oder?
Von diesem prototype erben alle Instanzen, also ist es der Ursprung der
Instanz, der in anderen Sprachen Klasse heißt.

Struppi.

J. Strübig wrote:

Frank Seitz schrieb:

Der Prototyp ist nur nicht das Objekt HTMLTextAreaElement,
sondern das Objekt HTMLTextAreaElement.prototype.

Wenn das Objekt einen prototype hat, ist es auch ein Prototyp, oder?

Das Objekt, das das prototype-Attribut hat, ist ein
Funktionsobjekt (der Konstruktor), das Objekt, das vom
prototype-Attribut referenziert wird, ist das
Prototyp-Objekt (der Prototyp).

Jedenfalls habe ich es so verstanden. Wenn mein Verständnis
richtig ist, ist HTMLTextAreaElement also kein Prototyp.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

"Frank Seitz" <devnull4711 (AT) web (DOT) de> schrieb im Newsbeitrag
news:63sdedF29csd1U1 (AT) mid (DOT) individual.net...

Geht das portabel? Welchen Klassennamen verwende ich?

Nachdem JS keine Klassen kennt: Keinen?

In OO-Sprechweise kann man HTMLTextAreaElement m.E. als
Klasse bezeichnen. Wie nennt man das sonst in JavaScript?

In der Literatur liest man oft von einem prototyp-basierendem
Klassenmodell.

Tatsächlich sind Javascripts Prototypen in vielen Fällen ein Ersatz
für Klassen in anderen Sprachen, aber eben nicht dasselbe. Daher
wird man, wenn man in Zusammenhang mit Javascript von Klassen
spricht, gerne von anderen auf diesen Unterschied hingewiesen, so
wie es dir jetzt (und auch mir schon früher) ergangen ist.

LG, Ferry
--

On 14 Mrz., 14:17, Frank Seitz <devnull4... (AT) web (DOT) de> wrote:

J. Strübig wrote:
Frank Seitz schrieb:
Das Objekt, das das prototype-Attribut hat, ist ein
Funktionsobjekt (der Konstruktor), das Objekt, das vom
prototype-Attribut referenziert wird, ist das
Prototyp-Objekt (der Prototyp).

Es gibt kein prototype Objekt, du kannst keines erzeugen.
Aber ein Prototyp hat eine prototype Eigenschaft. Alle von diesem
Prototyp erzeugten Instanzen haben die Eigenschaften, die mit
prototype definiert werden. Also ist der Prototyp vergleichbar mit
Klassen in anderen Programmiersprachen. Das ist auch der Begriff für
Klassen, den du in vielen Beschreibungen über OOP in Javascript
findest.

Struppi.

struppi wrote:

On 14 Mrz., 14:17, Frank Seitz <devnull4... (AT) web (DOT) de> wrote:
J. Strübig wrote:
Frank Seitz schrieb:
Das Objekt, das das prototype-Attribut hat, ist ein
Funktionsobjekt (der Konstruktor), das Objekt, das vom
prototype-Attribut referenziert wird, ist das
Prototyp-Objekt (der Prototyp).

Elemente und Interfaces haben Attribute; Objekte haben Eigenschaften.
Deine übrigen Aussagen sind korrekt (so steht es auch in der
ECMAScript-Spezifikation).

Es gibt kein prototype Objekt, du kannst keines erzeugen.
Aber ein Prototyp hat eine prototype Eigenschaft. Alle von diesem
Prototyp erzeugten Instanzen haben die Eigenschaften, die mit
prototype definiert werden. Also ist der Prototyp vergleichbar mit
Klassen in anderen Programmiersprachen. Das ist auch der Begriff für
Klassen, den du in vielen Beschreibungen über OOP in Javascript
findest.

Das ist grober Unfug!

Jeder Konstruktor und damit jedes Function-Objekt hat eine
prototype-Eigenschaft, die ein Object-Object referenziert. Dieses Objekt
heisst Prototyp(e)-Objekt oder kurz Prototyp. (Daraus folgt jedoch nicht,
dass jedes Objekt mit einer prototype-Eigenschaft auch ein Konstruktor sein
muss.)

Konstruktoren sind keine Prototyp-Objekte/Prototypen.

Prototypen sind nicht mit Klassen vergleichbar. Die Bezeichnung Klasse
für einen Konstruktor zu verwenden, ist falsch, und die entsprechenden
"Beschreibungen über OOP in JavaScript" daher fehlerhaft.


PointedEars
--
Wo im W3C-DOM für XML ist document.write spezifiziert? Nirgendwo. Das
geht also nicht, Du mußt das Dokument Knötchen für Knötchen aufbauen.
Soviel vom W3C zum Thema "Verstehen Sie Spaß???".
(Georg Maaß in dcljs <an91cq$c0ogv$1 (AT) ID-3551 (DOT) news.dfncis.de>)

Frank Seitz wrote:

Thomas 'PointedEars' Lahn wrote:
Frank Seitz wrote:
Das scheint nicht richtig zu sein, denn
HTMLTextAreaElement.prototype.f = function() { ... };

hat unter einem W3C-DOM-Browser funktioniert.
(Hatten wir das nicht vor kurzem erst?)

Weiß ich nicht, ich lese erst seit ein paar Tagen hier.

Du weisst doch sicher, dass hier die Verhaltensweise "suchen -- lesen --
denken -- posten" gern gesehen wird. Jedoch war es in diesem Fall eine
ernst gemeinte Frage, da ich mich nicht mehr erinnerte wo, sondern nur noch
dass dies kürzlich diskutiert wurde.

Man kann konkrete Host Objekte mit eigenen Eigenschaften anreichern -
ob es zuverlässig klappt sei dahingestellt.
Es ist zumindest riskant, da Host-Objekte ihre eigene Implementation von
[[Put]] verwenden dürfen. Alles von "nichts passiert" bis zu einem
Laufzeitfehler kann Ergebnis einer Zuweisung an eine Eigenschaft eines
Host-Objekts sein.

Bislang weise ich der Textarea-Instanz die Eigenschaften zu,
statt ein Wrapper-Objekt zu verwenden. Ist das grundsätzlich
problematisch

Ja.

oder nur in exotischen Sonderfällen?

Nein.

Was sind die Kriterien dafür?

Siehe oben und ECMAScript Language Specification, Edition 3 Final, Abschnitt
8.6.2.

Geht das portabel? Welchen Klassennamen verwende ich?
Nachdem JS keine Klassen kennt: Keinen?
Du nimmst mir die Worte aus dem Tastertur *g*

Ihr JavaScriptler habt IMO ein echtes Begriffsproblem
(siehe auch mein Posting <63ulh3F29csd1U5 (AT) mid (DOT) individual.net>).

Nein, u.a. "wir JavaScriptler" wissen jedoch, dass es nicht nur
klassenbasierte Objektorientierung gibt.

http://de.wikipedia.org/wiki/Prototy...Programmierung

Deine weiteren Argumente gegen den Begriff "Klasse" kann
ich nachvollziehen,

Gut.

die Bezeichnung "Host-Objekt" oder "DOM-Objekt" halte ich aber für
verfehlt, da sie den Unterschied zwischen Klasse und Objekt verwischt.

Keineswegs. Da es erstens in ECMAScript-Implementationen keine Klassen gibt
(siehe jedoch [1]) und zweitens so wie in funktionalen Programmiersprachen
Funktionen/Methoden Objekte (erster Klasse -- first-class objects -- heisst
nunmal so) sind, existiert eine strikte Trennung, wie Du sie von anderen
Programmiersprachen und -paradigmen anscheinend kennst, schlicht nicht.

Du selbst sprichst oben von "konkreten Host-Objekten" und meinst
damit Instanzen der Host-Objekte (die sowas wie Klassen oder
Interfaces sein sollen).

Das war *Gregors* Formulierung, und er hat Recht. Die ("konkreten")
(Host-)Objekte *implementieren* Interfaces. Das ist in anderen Sprachen und
anderen Programmierparadigmen nicht anders, worauf ich bereits hinwies.

Speziell für prototypbasierte Objektorientierung und in diesem Fall für
ECMAScript-Binding für einige Implementationen von W3C-DOM-Interfaces
ist, dass die Implementationen jener Interfaces, welche selbst natürlich
Host-Objekte (im ggs. zu nativen Objekten, die von der Sprache
bereitgestellt werden oder von bereitgestellten Prototypen erben)
darstellen, eine prototype-Eigenschaft bereitstellen, die ein (mgwl.
natives) Objekt referenziert, welches sich offenbar in der Prototypkette
von mit D::createElement() erstellten Host-Objekten befindet.

Vielleicht hilft Dir ein (gekürztes) UML(2)-Diagramm der
Gecko-1.8.x-DOM-Implementation zum Verstehen der Sachlage:

... <-. ,.

.---: nsIDOMNSHTMLTextAreaElement

.. | `'
nsIDOMHTMLElement :<-. | ,.
'' | | .-: nsIDOMNSHTMLElement

| | `'
,-----------------------'---. | |
interface>> | ,---'-'------------------.
nsIDOMHTMLTextAreaElement | | HTMLTextAreaElement: |
---------------------------| | Object |
accessKey | |------------------------|
cols | | ,--------------------. |
disabled |<- - -| | prototype:Object |-----. __proto__
... | | |--------------------| | |
---------------------------| | | accessKey | | |
blur() | | | cols | | |
... | | | disabled | | |
`---------,-----------------' | | ... | | |
| |--------------------| | |
,. | | blur() | | |

: : | | ... | | |
`' | `--------------------' | |
W3C DOM Level 2 HTML `---,--------------------' |
HTMLTextAreaElement |constructor |

|
.----------------'-------------------. |
document.createElement("textarea") : | |
HTMLTextAreaElement |---'
`.____________________________________.'

(siehe <http://xulplanet.com/references/objref/HTMLTextAreaElement.html>)

Das für klassisch ausgebildete Programmierer oft schwer verständliche
Paradigma der prototypbasierten OOP ist, dass ein Objekt (mindestens) von
einem anderen erben kann; ein Objekt ist der Prototyp eines anderen. Damit
wird zwar eine oft fehlervermeidende strenge Typbindung fast zwangsläufig
aufgegeben, jedoch gewinnt man eine nicht zu unterschätzende Flexibilität
bei der Implementierung.

Das ist zweimal fast dieselbe Bezeichnung für völlig verschiedenes.

Nein, das kommt Dir nur so vor.


PointedEars
--
CSS ist keine Darstellungsvorschrift, sondern ein Darstellungsvorschlag
mit eingebautem "Ich weiß es aber besser"-Recht auf Seiten des userAgent.

(Georg Maaß in dcljs <amuna7$9fbuu$1 (AT) ID-3551 (DOT) news.dfncis.de>)

Thomas 'PointedEars' Lahn schrieb:

struppi wrote:
Es gibt kein prototype Objekt, du kannst keines erzeugen.
Aber ein Prototyp hat eine prototype Eigenschaft. Alle von diesem
Prototyp erzeugten Instanzen haben die Eigenschaften, die mit
prototype definiert werden. Also ist der Prototyp vergleichbar mit
Klassen in anderen Programmiersprachen. Das ist auch der Begriff für
Klassen, den du in vielen Beschreibungen über OOP in Javascript
findest.

Das ist grober Unfug!

Steht aber so u.a. auch in den von dir verlinkten Artikeln.

Jeder Konstruktor und damit jedes Function-Objekt hat eine
prototype-Eigenschaft, die ein Object-Object referenziert.

Das ist exakt der grobe Unfug den ich oben erzählt habe.

Dieses Objekt
heisst Prototyp(e)-Objekt oder kurz Prototyp. (Daraus folgt jedoch nicht,
dass jedes Objekt mit einer prototype-Eigenschaft auch ein Konstruktor sein
muss.)

100% ACK, würde ich auch nie behaupten.

Prototypen sind nicht mit Klassen vergleichbar. Die Bezeichnung Klasse
für einen Konstruktor zu verwenden, ist falsch,

Das mag sein, nur schrieb ich 'vergleichbar' und was ist denn für dich
eine Klasse? Wikipedia schreibt:
Klasse ist in der Objektorientierung ein abstrakter Oberbegriff für die
Beschreibung der gemeinsamen Struktur und des gemeinsamen Verhaltens von
Objekten (Klassifizierung). Sie dient dazu, Objekte zu abstrahieren. Im
Zusammenspiel mit anderen Klassen ermöglichen sie die Modellierung eines
abgegrenzten Systems in der objektorientierten Analyse und dem
objektorientierten Design.

Diese Erklärung trifft nicht auf von Konstruktoren erzeugten Instanzen zu?

und die entsprechenden
"Beschreibungen über OOP in JavaScript" daher fehlerhaft.

Du meinst den von dir verlinkten Wikipedia Artikel über
protpypenbasierte Programmierung?
Ich lese den so, dass in JS (bzw. in der protpypenbasierte
Programmierung) auf die den Begriff Klasse verzichtet wird, stattdessen
verwendet man von prototypen.

Struppi.

Thomas 'PointedEars' Lahn wrote:

Frank Seitz wrote:

Bislang weise ich der Textarea-Instanz die Eigenschaften zu,
statt ein Wrapper-Objekt zu verwenden. Ist das grundsätzlich
problematisch

Ja.

oder nur in exotischen Sonderfällen?

Nein.

Was sind die Kriterien dafür?

Siehe oben und ECMAScript Language Specification, Edition 3 Final, Abschnitt
8.6.2.

"8.6.2. Internal Properties and Methods"
Habe mir das angesehen. An welcher Stelle steht denn, dass
sich Host-Objekte nicht erweitern lassen? Ich habe ja nicht vor,
interne Properties und Methoden zu überschreiben, sondern
will eigene Properties und Methoden hinzufügen.

Unter IE, Firefox, Safari habe ich im praktischen Test keine
Schwierigkeiten feststellen können.

Zur Diskussion, ob der Begriff "Klasse" im JavaScript-Kontext
angebracht ist: Ich komme von Perl her, da gibt es auch keine Klassen
im traditionellen Sinne und dennoch spricht man dort von "Klassen".
Das hat den Vorteil, dass wenigstens jeder weiß was gemeint ist.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Frank Seitz wrote:

Thomas 'PointedEars' Lahn wrote:
Frank Seitz wrote:
Bislang weise ich der Textarea-Instanz die Eigenschaften zu,
statt ein Wrapper-Objekt zu verwenden. Ist das grundsätzlich
problematisch
Ja.

oder nur in exotischen Sonderfällen?
Nein.

Was sind die Kriterien dafür?
Siehe oben und ECMAScript Language Specification, Edition 3 Final, Abschnitt
8.6.2.

"8.6.2. Internal Properties and Methods"
Habe mir das angesehen. An welcher Stelle steht denn, dass
sich Host-Objekte nicht erweitern lassen? Ich habe ja nicht vor,
interne Properties und Methoden zu überschreiben, sondern
will eigene Properties und Methoden hinzufügen.

Das läuft aber auf dasselbe hinaus. Schau Dir die Definition der internen
[[Put]]-Methode an.

Unter IE, Firefox, Safari habe ich im praktischen Test keine
Schwierigkeiten feststellen können.

Das mag sein, es ist jedoch ein klassischer Fehlschluss, dass dies dann auch
für alle anderen Host-Objekte und UAs gelten müsse. Ein (in *c.l.js bereits
bekanntes) einfaches Beispiel für IE 4 bis 7:

<div id="foo">&nbsp;</div>
<script type="text/javascript">
// "DIV"
window.alert(foo.tagName);

/*
* Laufzeitfehler:
* "Das Objekt unterstützt diese Eigenschaft oder Methode nicht"
*/
foo = 42;
</script>

Was ist hier passiert? Weshalb führt die einfache Zuweisung zu einem
harmlosen undeklarierten Bezeichner plötzlich zu einem Laufzeitfehler? Man
hätte doch erwartet, dass trotz fehlender Deklaration dem Globalen Objekt
einfach eine Eigenschaft mit dem Wert 42 hinzugefügt bzw. der Wert einer
vorhandenen Eigenschaft geändert worden wäre.

Aber `foo' ist hier ein unqualifizierter Bezeichner, folglich wird in der
Scope Chain das nächste Objekt gesucht, welches diese Eigenschaft hat (siehe
"10.1.4 Scope Chain and Identifier Resolution" in der Spezifikation). Und
offenbar gibt es bei diesem UA in der Scope Chain ein Host-Objekt, welches
eine Eigenschaft `foo' hat, welche das DOM-Objekt referenziert, welches das
Element mit der ID "foo" repräsentiert. Diese Eigenschaft ist nur leider
anscheinend read-only implementiert bzw. die [[Put]]-Methode des genannten
unbekannten Host-Objekts ist (völlig standardkonform) so implementiert, dass
in diesem Fall statt eines Schreibzugriffs eine Exception geworfen wird.

Dass es an dem unbekannten Host-Objekt liegt, wird deutlich, wenn man

<script type="text/javascript">
var foo;
foo = 42;
</script>

oder

<script type="text/javascript">
this.foo = 42;
</script>

schreibt, wo es jeweils keinen Laufzeitfehler gibt. (Ein wichtiger Grund,
weswegen alle Bezeichner deklariert werden sollten.)

Zur Diskussion, ob der Begriff "Klasse" im JavaScript-Kontext
angebracht ist: Ich komme von Perl her, da gibt es auch keine Klassen
im traditionellen Sinne und dennoch spricht man dort von "Klassen".
Das hat den Vorteil, dass wenigstens jeder weiß was gemeint ist.

Mit OOP in Perl habe ich mich zugegebenermassen noch zu wenig beschäftigt.
Nach Querlesen von `man perltoot' denke ich aber, dass Du Dich irrst:
Perl verfolgt anscheinend primär den klassenbasierten Ansatz der
objektorienten Programmierung. Objekte sind Instanzen von Klassen, und
Klassen erben nur von einer oder mehreren anderen Klassen.


PointedEars
--
Nein. Bei zwei nebeneinander angeordneten Bildschirmen ist der rechte
Rand des linken Bildschirms die Mitte des Desktops. Der rechte Rand des
Desktops ist der rechte Rand des rechten Bildschirms, und da geht es
nicht mehr weiter. (Lars Trebing in darw <3E1C9AC9.6233C9CA (AT) ltrebing (DOT) de>)