hallo again Christian,

was waere denn dann eine nicht strenge OO?

Ich meinte das im Sinne von:
JS kennt keine access modifier (public, private, ...)

die existenz bzw. nichtexistenz solcher modifier ist aber kein
kriterium, um eine sprachen nach OO, streng OO bzw. nach nicht
OO zu unterscheiden - kapselung, wofuer die von Dir genannten
modifier in klassenbasierter OO stehen, ist in diesem fall das
einzig ausschlaggebende kriterium fuer eine zuordnung.

kapselung laesst sich in funktionalen (@ christoph: im zusammenhang
mit JavaScript verzichte ich mal auf »rein«) programmierkonzepten
ohne weiteres abbilden und in JavaScript z.b. so:

gekapselte daten sind lokale werte bzw. objekte einer funktion.
diese begrenzte *sichtbarkeit* von daten kann bei datenstrukturen
durch ineinander verschachtelte funktionen (funktion in funktion)
gezielt ausgenutzt und über referenzierungskonzepte ebenso gezielt
getunnelt werden.

JS kennt keine Klassen ...

na und? - noch einmal ... in anderen worten:

die implementierung bzw. das fehlen eines klassenkonzepts sagt ganau
gar nichts darueber aus, ob eine sprache OO, streng OO, oder nicht OO
ist - vererbung ist hier das entscheidende kriterium.

... und keine Interfaces.

Du kennst JavaScript eben nicht richtig und schaust zusehr durch
die brille der klassenbasierten OO. [apply] und [call] sind die
beiden call-methoden, die dem konzept der interfaces in JavaScript
rechnung tragen. zugleich sind es die beiden methoden, die den
sex-appeal von JavaScript ausmachen, von klassenbasiert geschulten
programmierern leider aber uebersehen werden, weil diese oftmals
auf biegen und brechen versuchen, klassenbasierte vererbungskonzepte
ueber aufgeblasene konstruktoren und deren [prototype]-eigenschaft
in die sprachlandschaft hineinzuzimmern.

JS ist nicht typisiert.

dieses argument zaehlt ja nun mal gar nicht ;-) ... Smalltalk, die
mutter aller modernen OO-sprachen ist ja nun mal reinrassig OO und
dabei doch untypisiert  -  mantra: typisierung ist bei weitem kein
kriterium, um eine sprache nach ..., ... und ... zu unterscheiden.

Man kann JS auch prozedural schreiben.

na und? ...

• man kann in JavaScript sogar im 60er-stil rein imperativ, also
  komplett ohne kontrollstrukturen und ohne gegenseitige funktionsaufrufe,
  ja sogar ganz ohne funktionsrumpf schreiben.
• man kann JavaScript-code aber auch funktional (@Christian: stilistisch
  auch _rein_ funktional) oder eben objektorientiert schreiben.

Und ich finde all das macht _strenge_ OO aus.

nein.

Natürlich ist JS oo, ...

na also,

... aber halt nur halbherzig, ...

Du bist aber auch ein harter hund ;-)

imo.

• beschaeftige Dich bitte mit den grundlagen der informatik/programmierung.

hier mal ein zweiter besser ausformulierter entwurf, der versucht,
das sprachkonzept von JavaScript in aller kuerze zu beschreiben.

» Der als ECMAScript (ECMA 262) standardisierte Sprachkern von JavaScript
  kann ohne weiteres als Multiparadigmensprache bezeichnet werden. Obwohl
  im Grunde eine funktionale Skriptsprache, läßt sich in JavaScript sowohl
  prozedural als auch rein funktional bzw. objektorientiert programmieren.

In JavaScript representieren sich alle Daten bis auf die typen [Undefined]
  und [Null] bzw. bis auf die primitiven Werte [boolean], [number] und [string]
  als Objekte. Funktionen sind ebenfalls Objekte, deren im Funktionsrumpf
  gebundenen Anweisungen über den call-Operator bzw. über call-Methoden
  ausgeführt werden.

Gekapselte Daten sind lokale Werte bzw. Objekte einer Funktion. Diese
  begrenzte *Sichtbarkeit* von Daten kann bei Datenstrukturen durch ineinander
  verschachtelte Funktionen (Funktion in Funktion) gezielt ausgenutzt und über
  Referenzierungskonzepte ebenso gezielt getunnelt werden.

Schon auf dieser Grundlage läßt sich fuer alle nativen JavaScript-Objekte das
  Signal-Slot-Konzept implementieren, sodaß ereignisorientiertes Programmieren,
  auch losgelöst von DOM-Events, allein mit den Mitteln des Sprachkerns möglich
  ist.

Vererbung wiederum erfolgt in JavaScript ausschließlich über Delegation;
  entweder direkt über eine der call-Methoden oder implizit über den Objekt-
  Prototypen eines jeden Objekt-Konstruktors. Letztgenannter leistet dabei
  die Abstraktion zur Vererbung (im Sinne von *ist ein*), während die zuerst
  angesprochenen Methoden der Umsetzung des Aggregationskonzepts (*hat ein*)
  dienlich sind.«

so long - peterS. - pseliger@gmx.net