Zwei Fragen zu intrinsischen Objekten
0 0 0 
Der Martin
0 0 0 Der Martin
0 
molily
0 0 0 Der Martin
1 molily
0
Zwei Fragen zu intrinsischen Objekten
Hallo,
JavaScript kennt zwei Objekte (globales Objekt und Math-Objekt), die unmittelbar zur Verfügung stehen, also nicht mittels Konstruktor erzeugt werden müssen.
Frage 1: Sind das die beiden einzigen Objekte, die nicht explizit erzeugt werden müssen?
Ich bezeichne solche Objekte als intrinsisch.
Frage 2: Würdet ihr dieser Definition zustimmen oder den Begriff "intrinsisch" weiter fassen, in dem Sinne, dass er alle Objekttypen (Array, Date, ...), die JavaScript kennt, umfasst?
Gruß Uwe
-
[quote]
Intrinsic objects are Number, String, Boolean, Date, RegExp, and Math.
[/quote]
http://developer.mozilla.org/en/docs/About_JavaScriptmfg Beat
-
Hallo Beat,
vielen Dank für deine Antwort.
[quote]
Intrinsic objects are Number, String, Boolean, Date, RegExp, and Math.
[/quote]Die Aussage ist eigentlich nichtssagend, die tatsächliche Frage ist doch, was mach diese Objekte zu intrinsischen Objekten oder anders ausgedrückt, was unterscheidet diese (intrinsischen) Objekte von nicht-intrinsischen Objekten?
Gruß Uwe
-
Hallo,
Intrinsic objects are Number, String, Boolean, Date, RegExp, and Math.
Die Aussage ist eigentlich nichtssagend, ...sie hat für mich den Charakter einer Definition: Eine willkürliche Festlegung ohne eine Erklärung, *warum* dies so definiert wurde.
die tatsächliche Frage ist doch, was mach diese Objekte zu intrinsischen Objekten oder anders ausgedrückt, was unterscheidet diese (intrinsischen) Objekte von nicht-intrinsischen Objekten?
Diese rhetorische Frage drückt im Prinzip das gleiche aus.
Abgesehen davon habe ich mich schon immer gefragt, warum die Entwickler von Javascript (bzw. ECMA-Script) auf die Idee kamen, die mathematischen Funktionen und Konstanten in ein eigentlich nutzloses Objekt zu verpacken, anstatt sie als globale Funktionen zu implementieren. Bringt das einen Vorteil?
Ich sehe keinen; ich sehe nur den Nachteil des Mehraufwands beim Schreiben der Funktionsaufrufe.So long,
Martin--
Schon gewusst, dass Aftershave trotz des Namens eigentlich eher fürs Gesicht gedacht ist?-
Hallo Martin!
Intrinsic objects are Number, String, Boolean, Date, RegExp, and Math.
Die Aussage ist eigentlich nichtssagend, ...sie hat für mich den Charakter einer Definition: Eine willkürliche Festlegung ohne eine Erklärung, *warum* dies so definiert wurde.
die tatsächliche Frage ist doch, was mach diese Objekte zu intrinsischen Objekten oder anders ausgedrückt, was unterscheidet diese (intrinsischen) Objekte von nicht-intrinsischen Objekten?
Diese rhetorische Frage drückt im Prinzip das gleiche aus.
Ja, schon richtig, wobei es mir aber um die Definition von "intrinsisch" geht.
Abgesehen davon habe ich mich schon immer gefragt, warum die Entwickler von Javascript (bzw. ECMA-Script) auf die Idee kamen, die mathematischen Funktionen und Konstanten in ein eigentlich nutzloses Objekt zu verpacken, anstatt sie als globale Funktionen zu implementieren. Bringt das einen Vorteil?
Ich sehe keinen; ich sehe nur den Nachteil des Mehraufwands beim Schreiben der Funktionsaufrufe.Gute Frage, ich sehe auch keinen Vorteil. Wahrscheinlich gibt es auch keinen wirklichen Grund dafür.
Aber noch einmal zu meiner ersten Frage: JavaScript kennt zwei Objekte (globales Objekt und Math-Objekt), die unmittelbar zur Verfügung stehen, also nicht mittels Konstruktor erzeugt werden müssen.
Frage 1: Sind das die beiden einzigen Objekte, die nicht explizit erzeugt werden müssen?
Gruß Uwe
-
Hallo Uwe,
Intrinsic objects are Number, String, Boolean, Date, RegExp, and Math.
die tatsächliche Frage ist doch, was mach diese Objekte zu intrinsischen Objekten oder anders ausgedrückt, was unterscheidet diese (intrinsischen) Objekte von nicht-intrinsischen Objekten?von der Wortherkunft bedeutet "intrinsisch" soviel wie "aus eigenem Antrieb" oder auch "innewohnend". Bezogen auf die Javascript-Objekte würde ich das so verstehen, dass intrinsische Objekte diejenigen sind, "die schon drin sind", von denen man also keine Instanz erzeugen muss. Das wären dann aber nur window (das globale Objekt) und Math, passt also nicht zur obigen Aufzählung.
Sind intrinsische Objekte vielleicht diejenigen, deren Bauart (Konstruktor) von Javascript schon vorgegeben ist? Das wären alle oben genannten, zusätzlich aber auch z.B. Array und Object. Pass auch wieder nicht.
Ja, schon richtig, wobei es mir aber um die Definition von "intrinsisch" geht.
Es scheint also so, als wäre das im Falle von Javescript tatsächlich nach Gutdünken definiert, ohne dass es eine Erklärung oder Begründung gibt. Denn ich finde nichts, was auf alle oben genannten, aber auf keine anderen JS-Objekte zutrifft.
[Math-Objekt]
ich sehe nur den Nachteil des Mehraufwands beim Schreiben der Funktionsaufrufe.
Gute Frage, ich sehe auch keinen Vorteil. Wahrscheinlich gibt es auch keinen wirklichen Grund dafür.Aha. Der fehlt also ebenso wie die Erklärung des Begriffs "intrinsisch". ;-)
Frage 1: Sind das die beiden einzigen Objekte, die nicht explizit erzeugt werden müssen?
Mir fällt kein weiteres ein. Was wäre dann Frage 2?
So long,
Martin--
Lache, und die Welt wird mit dir lachen.
Schnarche, und du schläfst allein.-
Hallo Martin!
Frage 1: Sind das die beiden einzigen Objekte, die nicht explizit erzeugt werden müssen?
Mir fällt kein weiteres ein.Danke, Frage beantwortet.
Was wäre dann Frage 2?
Die hast du doch auch schon beantwortet, also nochmal danke :-)
Frage 1: Sind das die beiden einzigen Objekte, die nicht explizit erzeugt werden müssen?
Ich bezeichne solche Objekte als intrinsisch.
Frage 2: Würdet ihr dieser Definition zustimmen oder den Begriff "intrinsisch" weiter fassen, in dem Sinne, dass er alle Objekttypen (Array, Date, ...), die JavaScript kennt, umfasst?... dass intrinsische Objekte diejenigen sind, "die schon drin sind", von denen man also keine Instanz erzeugen muss ...
Das Zauberwort ist hier "keine Instanz erzeugen" - genau so definiere ich intrinsisch. Es ist ja kein JavaScript spezifischer Begriff und von daher ...
Intrinsic objects are Number, String, Boolean, Date, RegExp, and Math.
... halte ich diese Definition für unsinnig.
Vielleicht könnte man ein intrinsisches Objekt einfach mit einer statischen Klasse gleichsetzen?
Gruß Uwe
-
-
-
Hi,
Abgesehen davon habe ich mich schon immer gefragt, warum die Entwickler von Javascript (bzw. ECMA-Script) auf die Idee kamen, die mathematischen Funktionen und Konstanten in ein eigentlich nutzloses Objekt zu verpacken, anstatt sie als globale Funktionen zu implementieren.
Warum sollte man sie nicht als Methoden eines gemeinsamen Objekts implementieren? Sie haben doch alle gemeinsam, dass sie eben "mathematischer" Natur sind.
Ich sehe keinen; ich sehe nur den Nachteil des Mehraufwands beim Schreiben der Funktionsaufrufe.
Och du Armer ... dann muss dir das OO-Konzept ja generell ein Dorn im Auge sein? Immer diese "laestigen" Objekte, wo man doch eigentlich alles so schoen global und prozedural handeln koennte ... ;-)
MfG ChrisB
--
"The Internet: Technological marvel of marvels - but if you don't know *what* you're lookin' for on the Internet, it is nothing but a time-sucking vortex from hell."-
Hallo Chris,
Ich sehe keinen; ich sehe nur den Nachteil des Mehraufwands beim Schreiben der Funktionsaufrufe.
Och du Armer ... dann muss dir das OO-Konzept ja generell ein Dorn im Auge sein?stimmt ...
Immer diese "laestigen" Objekte, wo man doch eigentlich alles so schoen global und prozedural handeln koennte ... ;-)
Du sprichst mir aus der Seele.
Aber das ist nicht der einzige Grund, warum ich OOP, wie sie oft realisiert ist, nicht mag. Der entscheidende Grund ist jedoch, dass der Code dadurch zwar aufgeräumter, aber meist viel schwieriger nachvollziehbar wird.Ciao,
Martin--
Viele Fachleute vertreten die Ansicht, jedes Feature eines Programms, das sich nicht auf Wunsch abstellen lässt, sei ein Bug.
Außer bei Microsoft. Da ist es umgekehrt. -
Hallo,
dann muss dir das OO-Konzept ja generell ein Dorn im Auge sein? Immer diese "laestigen" Objekte, wo man doch eigentlich alles so schoen global und prozedural handeln koennte ... ;-)
Genau. Möge er PHP programmieren, mit 45.391 globalen Funktionen!
Mathias
-
-
-
-
-
Hallo,
JavaScript kennt zwei Objekte (globales Objekt und Math-Objekt), die unmittelbar zur Verfügung stehen, also nicht mittels Konstruktor erzeugt werden müssen.
Frage 1: Sind das die beiden einzigen Objekte, die nicht explizit erzeugt werden müssen?
Man kann ja z.B. auch schreiben Date.UTC(). In diesem Falle muss auch kein Date Objekt erstellt werden.
Ich weiß nicht was intrinsisch bedeutet, aber wie Der Martin schon schön beschrieben hat, scheint es eher willkür zu sein.
Ich bezeichne solche Objekte als Objekte mit statischen Methoden. Bzw. es gibt ja auch Objekte wie eben Date oder auch String (.fromCharCode), die sowohl statische als auch nicht-statische Methoden aufweisen. Daher würde ich einfach sagen, die Methode ist statisch oder eben nicht. Das ist eigentlich auch die terminologie bei richtigen OO-Sprachen.
Oft wird auch von eine Instanz- oder einer Klassen-Methode gesprochen. Bei der Instanz-Methode ist die Methode eben an der Instanz dran, und sonst braucht man eben keine Instanz zu erzeugen, um die Methode aufzurufen.
Nun gibt es natürlich nur keine richtigen Klassen in JavaScript...Frage 2: Würdet ihr dieser Definition zustimmen oder den Begriff "intrinsisch" weiter fassen, in dem Sinne, dass er alle Objekttypen (Array, Date, ...), die JavaScript kennt, umfasst?
Vielleicht eher letzteres. Objekte und Methoden, die die Sprache von Haus aus mitbringt, trifft es vielleicht.
Zu der Frage, weshalb man die Math Funktionen nicht global gemacht hat:
Das würde doch nur unübersichtlicher werden, bzw. es ist doch der Sinn einer objektorientierten Sprache, die Methoden strukturiert in Namespaces und Klassen unterzubringen. Und früher oder später gäbs dann Namenskonflikte. Man könnte dann z.B. keine Variable mehr E nennen und gleichzeitig auf die eulersche Zahl zugreifen...
Mag blöd erscheinen, aber ich finde sowas gehört zum guten Design, also die Strukturierung zusammengehörender Funktionen in ein Oberobjekt.Gruß
Christian-
Hallo Christian,
Zu der Frage, weshalb man die Math Funktionen nicht global gemacht hat:
Das würde doch nur unübersichtlicher werden, bzw. es ist doch der Sinn einer objektorientierten Sprache, die Methoden strukturiert in Namespaces und Klassen unterzubringen. Und früher oder später gäbs dann Namenskonflikte. Man könnte dann z.B. keine Variable mehr E nennen und gleichzeitig auf die eulersche Zahl zugreifen...
Mag blöd erscheinen, aber ich finde sowas gehört zum guten Design, also die Strukturierung zusammengehörender Funktionen in ein Oberobjekt.Nein, überhaupt nicht blöd, ich nehme zurück, was ich dazu gesagt habe, du hast absolut recht.
Frage 2: Würdet ihr dieser Definition zustimmen oder den Begriff "intrinsisch" weiter fassen, in dem Sinne, dass er alle Objekttypen (Array, Date, ...), die JavaScript kennt, umfasst?
Vielleicht eher letzteres. Objekte und Methoden, die die Sprache von Haus aus mitbringt, trifft es vielleicht.
Würde ich nicht, denn dann müsste ich mir keinen abbrechen und den Begriff "intrinsisch" verwenden, dann könnte ich einfach innewohnend, immanent oder was weiß ich sagen. Ich kenne ihn, beispielsweise aus der Windows-Programmierung, als relativ geläufigen Begriff, hab aber nie irgendwie eine exakte Definition gesehen und in der Praxis immer erlebt, dass er widersprüchlich verwendet wird. Ich glaube, ich schenk mir diesen Begriff in Zukunft einfach.
Gruß Uwe
-
Hi,
Zu der Frage, weshalb man die Math Funktionen nicht global gemacht hat:
Das würde doch nur unübersichtlicher werden, bzw. es ist doch der Sinn einer objektorientierten Sprache, die Methoden strukturiert in Namespaces und Klassen unterzubringen.ja schon, aber dann doch in einem Kontext, in dem sie Sinn ergeben. Wenn man schon die mathematischen Funktionen in einem Objekt bzw. in einer Klasse kapseln möchte, dann z.B. im Number-Objekt (weil alle Math-Funktionen auf Argumenten vom Typ Number arbeiten), ebenso wie einige Stringfunktionen an das String-Objekt gebunden sind. Aber nur der Kapselung wegen ein unabhängiges Objekt zu bauen, halte ich für unsinnig.
Abgesehen davon bin ich der Ansicht, dass "allgemeingültige" Funktionen, die von ihrer Arbeitsweise her nicht an spezialisierte Objekte (in diesem Sinn bezeichne ich Primitive wie Number oder String nicht als spezialisierte Objekte) gebunden sind, auch im globalen Scope verfügbar sein sollten, denn da gehören sie IMHO hin.
Und früher oder später gäbs dann Namenskonflikte. Man könnte dann z.B. keine Variable mehr E nennen und gleichzeitig auf die eulersche Zahl zugreifen...
Ja, mit den vordefinierten Variablen bzw. den mathematischen Konstanten ist das ein besonderer Fall, da JS keine Konstanten kennt.
Mag blöd erscheinen, aber ich finde sowas gehört zum guten Design, also die Strukturierung zusammengehörender Funktionen in ein Oberobjekt.
Ja, Strukturierung gern - aber dann bitte mit Verstand, nicht nach Willkür, nur damit die Funktionen "aufgeräumt" sind.
Ciao,
Martin--
Kleine Geschenke erhalten die Freundschaft.
Große verderben sie aber meist auch nicht. -
Hallo,
Objekte und Methoden, die die Sprache von Haus aus mitbringt, trifft es vielleicht.
Die »Sprache« gibts halt nicht. Es gibt ECMAScript, und die unterscheidet zwischen sog. native objects, das sind v.a. die besagten Konstruktoren sowie die vordefinierten Member deren Prototypen, und sog. host objects, das sind die von der ECMAScript-Anwendung gelieferten Objekte (z.B. document, screen, history, location...). Wobei das nicht sauber trennbar ist, denn window wird in ECMAScript allgemein als das sog. global object definiert, gehört daher zu den native objects, enthält aber natürlich auch host objects. ECMAScript definiert da also das Gerüst bzw. die Vorlage.
Diese Unterscheidung ist eigentlich nur interessant für das Verständnis des Aufbaus der JavaScript-Objektwelt, denn die native objects bzw. built-in objects sind grundlegender und beziehen sich nicht auf die darüberliegende Schicht WWW, Browserfenster, Dokument. Das ist halt einfach der Unterschied zwischen allgemeiner Sprachgrundlage (ECMAScript) und konkrete Anwendung (»JavaScript« auf Webseiten). Von dieser nützlichen, weil verständnisfördernden Unterscheidung abgesehen habe ich es bisher nicht für nötig empfunden, mit Begriffen wie »intrinsisch« zu operieren.
Mathias
-
-
Moin.
Das ist letzlich Definitionssache. Eine sinnvolle Definition wäre z.B. alle Konstruktoren, die die Laufzeitumgebung standardmäßig bereitstellt.
Intrinsische Objekte wären damit z.B. Array, Boolean, Function, Object, String, SyntaxError,...
Keine intrinsischen Objekte wären z.B. decodeURI, document, Math, window,... - diese Objekte und Funktionen werden zwar von der Laufzeitumgebung automatisch im globalen Namensraum bereitgestellt, sind aber keine Konstruktoren...
Christoph
-
Hallo Christoph!
Das ist letzlich Definitionssache.
Ja, so wird es wohl sein.
Eine sinnvolle Definition wäre z.B. alle Konstruktoren, die die Laufzeitumgebung standardmäßig bereitstellt.
Intrinsische Objekte wären damit z.B. Array, Boolean, Function, Object, String, SyntaxError,...
Keine intrinsischen Objekte wären z.B. decodeURI, document, Math, window,... - diese Objekte und Funktionen werden zwar von der Laufzeitumgebung automatisch im globalen Namensraum bereitgestellt, sind aber keine Konstruktoren...
Wäre eine Möglichkeit, wobei ich da eher bei meiner Definition bleiben würde, ich muss das mal überdenken. Vielleicht ist es das Beste auf den Begriff einfach zu verzichten, denn es bringt ja nichts einen Begriff zu verwenden, den man jedesmal definieren muss.
Gruß Uwe
-
Hallo,
Vielleicht ist es das Beste auf den Begriff einfach zu verzichten
Toll, wieder mal ein JavaScript-Theorie-Thread, bei dem man nachher so klug ist wie vorher. ;) Nehmen die in letzter Zeit überhand oder kommt mir das nur so vor?
Mathias
-
Hallo Mathias!
Toll, wieder mal ein JavaScript-Theorie-Thread, bei dem man nachher so klug ist wie vorher. ;)
Nehmen die in letzter Zeit überhand oder kommt mir das nur so vor?Keine Ahnung ;-)
Ich war mit dem Begriff "intrinsisch" noch nie glücklich und deswegen mein Gedanke darauf zu verzichten. Ich kenne ihn als geläufigen und programmiersprachenunabhängigen Begriff beispielsweise aus dem Bereich des Scripting unter Windows.
Und es geht dabei genau um das Spannungsverhältnis zwischen der Laufzeitumgebung, dem Host, und der konkreten Programmiersprache, was du weiter unten angesprochen hast. Ein "intrinsisches" Objekt kann gemäß meiner Definition, sowohl ein Objekt des Hosts als auch der Programmiersprache sein. "Intrinsisch" bezieht sich dabei auf die Art und Weise, wie ich auf ein Objekt zugreifen kann.
Gruß Uwe
-
Hi,
Toll, wieder mal ein JavaScript-Theorie-Thread, bei dem man nachher so klug ist wie vorher. ;) Nehmen die in letzter Zeit überhand oder kommt mir das nur so vor?
Das kommt dir nur so vor, weil du in Bezug auf JavaScript schon so klug bist, dass viel "mehr" in deinem Falle einfach nicht mehr geht :-)
MfG ChrisB
--
"The Internet: Technological marvel of marvels - but if you don't know *what* you're lookin' for on the Internet, it is nothing but a time-sucking vortex from hell."-
Hallo,
Das kommt dir nur so vor, weil du in Bezug auf JavaScript schon so klug bist, dass viel "mehr" in deinem Falle einfach nicht mehr geht :-)
Das glaube ich nicht. Die JavaScript-Welt ist mittlerweile so groß und fragmentiert, dass ich da alles andere als einen Überblick habe. Da gibt es tausende Bereiche, die Universen für sich sind, von denen ich überhaupt keine Ahnung habe.
Bei gewissen Diskussionen hier komme ich auch nicht mit. Muss ich natürlich nicht, aber ich frage mich dann, welche Praxisrelevanz z.B. gewisse esoterische OOP-Diskussionen haben. Richtiges, komplexes OOP mit »Klassen« und Vererbung hat in der JavaScript-Praxis meiner Erfahrung nach nur äußerst wenige Anwendungsbereiche. 95% der Fälle kann man mit Object-Literalen, einfachem OOP (ein Konstruktor, ein paar Eigenschaften und Methoden, einfache Instantiierung) sowie prototypischer Erweiterung der Kernobjekte abfrühstücken. Wenn man das einigermaßen beherrscht, kann man schon sehr gutes JavaScript schreiben.
Gerade weil es in JavaScript kein vorgegebenes komplexes OOP gibt, kann man unzählige eigene OOP-Pattern erfinden und übertragen (»fix it with more JavaScript«). An der Diskussion habe ich mich noch nie beteiligt, weil ich sie bei meiner Arbeit noch nie gebraucht habe. Solch komplexen Code halte ich auch für unverständlich und unwartbar, ich bevorzuge dann »KISS«. Das nur als Beispiel, wie sich theoretische Diskussionen auch einfach abheben können. Ich finde es durchaus sinnvoll, dieses Wissen zu erarbeiten, aber beim täglichen Arbeiten hilft sowas nur indirekt weiter. Die Fragen zu OOP hier sind dann doch eher Basics wie »Funktion im Kontext eines Objektes ausführen«.
Mathias
-
-
-
-