was bewirkt {}

[Ric]

Hallo Selfler

Ich weis zufällig das bei var x = []; var x = new Array(); gemeint ist aber was bewirkt var x = {}; ??

[Don P]

Hallo,

was bewirkt var x = {}; ??

Das ist identisch mit
var x = new Object();

Gruß, Don P

[KurtZ]

Kurtz beantwortet:

Ich weis zufällig das bei var x = []; var x = new Array(); gemeint ist aber was bewirkt var x = {}; ??

var x = new Object();

ist aber gleichzeitig JS Form eines assoziativen Arrays!

x={a:1};
x.a == 1;

Grüße
 Kurt

[Don P]

Hallo,

ist aber gleichzeitig JS Form eines assoziativen Arrays!

Es gibt keine assoziativen Arrays in JavaScript, nur normale Arrays oder eben Objekte. Was du "assoziatives Array" nennst ist ein normales Objekt mit Eigenschaften/Methoden. Der Unterschied ist, dass echte Arrays eine Eigenschaft namens length haben, das ist die Anzahl der Arrayeinträge. Ein "assoziatives Array" bzw. ein normales Objekt hat keine Eigenschaft length, und falls doch, sie gibt nicht die Anzahl der Eigenschaften/Methoden zurück.

var array = [];
array.prop1 = 1;
array.prop2 = 2;
alert(array.length); // 0

Gruß, Don P

[KurtZ]

Jedes Object ist als hash table realisiert, will man also ein Hash dann muss man Object nehmen, oder halt {}.

Array hat übrigens noch mehr methoden und eigenschaften.

[Don P]

Hallo,

Jedes Object ist als hash table realisiert, will man also ein Hash dann muss man Object nehmen, oder halt {}.

Das ist klar, hat aber nichts mit einem Array zu tun, abgesehen davon, dass es natürlich auch eine Auflistung ist. Im Array spielt z.B. die Reihenfolge der Einträge eine Rolle, im Object nicht.

Array hat übrigens noch mehr methoden und eigenschaften.

Ich weiß, aber length ist die entscheidende Eigenschaft, die das Ding erst zu einem Array macht. Ein "asoziatives Array" oder ein Hash hat diese Eigenschaft meines Wissens auch. Aber in JavaScript gibt es das so nicht. Daher ist es einfach irreführend, von assoziativen Arrays in JavaScript zu sprechen.

Gruß, Don P

[KurtZ]

oh mein gott! kennst du den unterschied zwischen hashes und arrays?

[Don P]

Hallo,

oh mein gott! kennst du den unterschied zwischen hashes und arrays?

Ich denke, ja: Die einen haben numerische Indizes, die anderen Strings.
Wenn du's besser weißt, dann immer her damit.

Gruß, Don P

[KurtZ]

Schon mal gut, dann erkläre mir bitte wie du hashes  JS realisierst...

[Cheatah]

Hi,

Schon mal gut, dann erkläre mir bitte wie du hashes  JS realisierst...

herrje. Indem ich mir eine Klasse namens Hash baue natürlich.

Cheatah

[KurtZ]

Hi

Verrätst du mir bitte, wie du verhinderst dass Hash von Object.prototype erbt?

Foo-Grüße
 Kurt

[Don P]

Hallo,

Verrätst du mir bitte, wie du verhinderst dass Hash von Object.prototype erbt?

Ok dann, wenn du es unbedingt so willst, obwohl es eben nicht üblich ist, in JavaScript von assoziativen Arrays oder Hashes zu sprechen, wie dir die Kenner hier bestätigen.

Es gibt aber anscheinend auch andere Meinungen, z.B. in der engl. Wikipedia, wo es zum Stichwort "associative array" u.a. heißt:
"In the scripting language Lua, associative arrays, called tables, are used as the primitive building block for all data structures, even arrays. Likewise, in JavaScript, all objects are associative arrays."

Zufrieden? Aber schießlich ist das nur Wikipedia, wo jeder reinschreibt, was er so meint, bis es anderen gegen den Strich geht...

Im entsprechenden Artikel der dt. Wikipedia ist JavaScript überhaupt nicht erwähnt. Richtigerweise, wie ich finde.

Gruß, Don P

[KurtZ]

Hi

Ok dann, wenn du es unbedingt so willst, obwohl es eben nicht üblich ist, in JavaScript von assoziativen Arrays oder Hashes zu sprechen, wie dir die Kenner hier bestätigen.

Wenn ich die Wahl habe zwischen O'Reilly Autoren und hiesigen Kennern fällt mir die Wahl schwer, sehr schwer...

Überzeugen würde mich natürlich ein Codebeispiel der "Kennner" ... sogar mehr noch als WP.

Aber das wird langweilig
 Kurt

[Siechfred]

Wenn ich die Wahl habe zwischen O'Reilly Autoren und hiesigen Kennern fällt mir die Wahl schwer, sehr schwer...

Siehe molily zu der Frage, warum im Javascript-Kapitel von SELFHTML von "Assoziativen Arrays" die Rede ist. Ähnlich dürfte der Fall bei O'Reilly liegen. Aber molily ist wie ich auch nur interessierter Laie, so what...

Siechfred

[Cheatah]

Hi,

Verrätst du mir bitte, wie du verhinderst dass Hash von Object.prototype erbt?

welchen Vorteil sollte es bringen, wenn das nicht passieren würde?

Cheatah

[Don P]

Hallo,

Jedes Object ist als hash table realisiert, will man also ein Hash dann muss man Object nehmen, oder halt {}.

Das stimmt so überigens auch nicht. Für dein "assoziatives Array" könnte man alles mögliche heranziehen, außer {} z.B. auch RegExp oder [].

Gruß, Don P

[KurtZ]

Hi

Jedes Object ist als hash table realisiert, will man also ein Hash dann muss man Object nehmen, oder halt {}.

Das stimmt so überigens auch nicht.

Typo: sollte heißen jedes "Objekt" (Deutsch) und nicht Object() (JS-Konstruktor)

Für dein "assoziatives Array" könnte man alles mögliche heranziehen, außer {} z.B. auch RegExp oder [].

soso ... und darf ich fragen was du normalerweise heranziehst?

gruß
 Kurt

[Don P]

Hallo,

soso ... und darf ich fragen was du normalerweise heranziehst?

Nein.

Gruß, Don P

[KurtZ]

Hi

soso ... und darf ich fragen was du normalerweise heranziehst?

Nein.

dachte ich mir :)

Bye
  KurtZ

[Cheatah]

Hi,

ist aber gleichzeitig JS Form eines assoziativen Arrays!

Object.prototype.foo = 42;
var x = {a: 1, b: 2};
for (var i in x) { alert(i+"\n"+x[i]); }

Ich schätze, diese Behauptung stellst Du nun nie wieder auf.

Cheatah

[KurtZ]

Ich schätze, diese Behauptung stellst Du nun nie wieder auf.

doch!

dann verate mir mal wie du hashes implementierst!

[Siechfred]

Ich schätze, diese Behauptung stellst Du nun nie wieder auf.
doch!

Nein :)

dann verate mir mal wie du hashes implementierst!

Es gibt in Javascript keine Hashes.

Siechfred

[KurtZ]

HI

dann verate mir mal wie du hashes implementierst!

Es gibt in Javascript keine Hashes.

... deswegen verzichtest du also auf sie ?

Grüße
 Kurt

[Cheatah]

Hi,

dann verate mir mal wie du hashes implementierst!
Es gibt in Javascript keine Hashes.
... deswegen verzichtest du also auf sie ?

nein. Aber deswegen stelle ich nicht die absurde Behauptung auf, Objekte seien welche.

Cheatah

[KurtZ]

Hi

nein. Aber deswegen stelle ich nicht die absurde Behauptung auf, Objekte seien welche.

Schonmal gut, dann verrate uns bitte wie du sie realisierst!

Kurt

[Siechfred]

nein. Aber deswegen stelle ich nicht die absurde Behauptung auf, Objekte seien welche.
Schonmal gut, dann verrate uns bitte wie du sie realisierst!

Als Eigenschaften eines selbst definierten Objects. Doch dieser "Umweg" macht Objekte nicht zu assoziativen Arrays oder Hashes.

Siechfred

[KurtZ]

Hi

Als Eigenschaften eines selbst definierten Objects.

Bitte, ganz ehrlich, erleuchte mich und zeige mir diesen selbstdefinierten Konstruktor. Mir ist komplett schleierhaft wie der so realisiert werden soll dass es besser wird als {} außer dass er länger wird.

Gruß
 Kurt

[Siechfred]

Als Eigenschaften eines selbst definierten Objects.
Bitte, ganz ehrlich, erleuchte mich und zeige mir diesen selbstdefinierten Konstruktor. Mir ist komplett schleierhaft wie der so realisiert werden soll dass es besser wird als {} außer dass er länger wird.

var x = { foo: 42 }

bewirkt das gleiche wie

var x = new Object();  
x.foo = 42;

Trotzdem ist und bleibt x ein Objekt, kein Hash oder assoziatives Array. Deutlich wird dies, indem Du einfach mal solche Sachen wie x.prototype oder x.constructor abfragst - das sind Methoden. Und dass ein Hash keine Methoden hat, ist m.E. unstrittig.

Siechfred

[KurtZ]

Hi

Trotzdem ist und bleibt x ein Objekt, kein Hash oder assoziatives Array. Deutlich wird dies, indem Du einfach mal solche Sachen wie x.prototype oder x.constructor abfragst - das sind Methoden. Und dass ein Hash keine Methoden hat, ist m.E. unstrittig.

In JS gibts nur primitive Datentypen und Objekte, demzufolge ist jeder nichtprimitive Datentyp ein Object, auch Array oder jedes ominöse Konstrukt das "Hash" realisieren könnte.

probier mal folgendes aus:

alert( [].constructor )

Kurt

[Don P]

Hallo,

In JS gibts nur primitive Datentypen und Objekte, demzufolge ist jeder nichtprimitive Datentyp ein Object, auch Array oder jedes ominöse Konstrukt das "Hash" realisieren könnte.

Ja doch. Aber ein Trike oder Motorrad ist z.B. in gewissem Sinn auch ein Auto, d.h. im wörtlichen Sinn ein Automobil, das sich quasi von selbst (auto) bewegt (mobil). Trotzdem würde niemand ein Auto als "Trike" als "Motorrad" bezeichnen, selbst dann nicht, wenn es ihm gelänge, dem Auto ein oder zwei Räder zu nehmen, ohne dass es umfällt.

Gruß, Don P

[Siechfred]

Deutlich wird dies, indem Du einfach mal solche Sachen wie x.prototype oder x.constructor abfragst - das sind Methoden.

Eigenschaften natürlich, Methoden wären z.B. toString oder toSource.

Siechfred

[Daniel Thoma]

Hallo Siechfred,

Was betreibt ihr den hier für absurde Wortklauberei?
Objekte in Javascript sind im wesentlichen assoziative Arrays und sehr wahrscheinlich auch meist als Hashtabellen implementiert.

Natürlich haben sie noch eine weitere Semantik. Aber sie sind von der Syntax her ja dafür ausgelegt, auch als assoziative Arrays verwendet zu werden. Dass sie noch weitere Semantik haben, tut dem keinen Abbruch.

Grüße

Daniel

[KurtZ]

Hi

Was betreibt ihr den hier für absurde Wortklauberei?
Objekte in Javascript sind im wesentlichen assoziative Arrays und sehr wahrscheinlich auch meist als Hashtabellen implementiert.

Natürlich haben sie noch eine weitere Semantik. Aber sie sind von der Syntax her ja dafür ausgelegt, auch als assoziative Arrays verwendet zu werden. Dass sie noch weitere Semantik haben, tut dem keinen Abbruch.

Danke, du stellst viel verlorenes Vertrauen in hiesige Strukturen wieder her.

Grüße
 Kurt

[Siechfred]

Was betreibt ihr den hier für absurde Wortklauberei?

Hm, Wortklauberei - von mir aus, aber dass sie absurd ist, finde ich nicht. Und bitte vergiss nicht, dass KurtZ hier die Schärfe reingebracht hat.

Objekte in Javascript sind im wesentlichen assoziative Arrays und sehr wahrscheinlich auch meist als Hashtabellen implementiert.

Nur weil was fliegt, ist es doch noch kein Flugzeug?

Natürlich haben sie noch eine weitere Semantik.

Eben, und deswegen sind sie Objekte und keine Hashes. Ich spreche da aus Erfahrung, da mich als jemand, der Hashes aus Perl kennt (wie KurtZ vermutlich auch), das Konzept von JS anfänglich durchaus verwirrt hat.

Siechfred

[Daniel Thoma]

Hallo Siechfred,

Und bitte vergiss nicht, dass KurtZ hier die Schärfe reingebracht hat.

Sehe ich nicht so, jedenfalls nicht alleine. Er hat angepisst auf rechthaberische Antworten reagiert.
Es handelt sich nunmal um Wortklauberei und diese doch eher philosophische Ansicht "Ein Objekt ist kein Hash", habt ihr beide rechthaberisch vertreten. Nun kann man meinetwegen der Meinung sein, dass man nicht von "Hashes" reden sollte, weil das zu falschen Erwartungen an das tatsächliche Verhalten führt. Aber hat ja weder Cheatah noch Du getan.

Nur weil was fliegt, ist es doch noch kein Flugzeug?

Nur weil etwas auch noch schwimmen kann, ist es kein Flugzeug mehr?
Es gibt einfach keine allgemeingültige Definition von "Hash" die über "Ordnet Schlüsseln Werten zu" hinausgeht. Gerade, dass der Begriff nicht klar definiert ist, hätte an dieser Stelle eine Argumentation notwendig gemacht.

Eben, und deswegen sind sie Objekte und keine Hashes. Ich spreche da aus Erfahrung, da mich als jemand, der Hashes aus Perl kennt (wie KurtZ vermutlich auch), das Konzept von JS anfänglich durchaus verwirrt hat.

Ja meinetwegen. Nur wenn man versucht jemanden mit "Ich schätze, Du stellst diese Behauptung nie wieder auf" und "In JS gibt es keine Hashes" zu überzeugen, wirkt das einfach nur Arrogant.
Kurt hätte da souveräner reagieren können, aber dass er sich angegangen fühlte, finde ich nachvollziehbar.

Grüße

Daniel

[Struppi]

Es gibt einfach keine allgemeingültige Definition von "Hash" die über "Ordnet Schlüsseln Werten zu" hinausgeht.

und genau diese Definition verhindert, von einem Hash oder AA zu sprechen, da die Schlüssel eben nicht unbedingt Werten zugeordnet sind, solange man nicht ausschliessen kann, dass prototype verwendet wird.

Da man dies aber durchaus im Rahmen seiner Anwendung als Bedingung vorrausetzen kann (solange man keine Frameworks/Bibliotheken verwendet die dies tun), ist es durchaus möglich Objekte in JS als Hash zu verwenden und man mag das dann auch im Rahmen seiner Anwendung so benennen.

Struppi.

[KurtZ]

... wir warten

du wollest uns eine "Klasse" Hash() bauen, über die gefahrlos mit "for in" iteriert werden kann.

Googlest du noch um deine "absurde" Behauptung zu untermauern???

Ich schätze, diese Behauptung stellst Du nun nie wieder auf.

Ich schätze eher dein Ego hat einen Knacks bekommen!

Kurt

[Don P]

Hallo,

... wir warten

du wollest uns eine "Klasse" Hash() bauen, über die gefahrlos mit "for in" iteriert werden kann.

Wollte cheatah das? Das hat er nirgends geschrieben. Abgesehen davon ist es kein Problem so eine Klasse zu bauen, aber natürlich wird die Sache länger, wenn sie zusätzliche Bedingungen erfüllen muss (gefahrlos mit "for in"), die ein Hash ja eigentlich von sich aus mitbringen sollte. Ein weiterer Beweis dafür, dass es Hashes, wie man sie normalerweise kennt, in JavaScript eben nicht gibt. Man müsste sie sich erst bauen.

Ich schätze eher dein Ego hat einen Knacks bekommen!

Du bist wohl zum Streiten hier oder zum unbedingt Rechthaben und wirst dazu auch noch persönlich...

Gruß, Don P

[KurtZ]

Hi

Du bist wohl zum Streiten hier oder zum unbedingt Rechthaben und wirst dazu auch noch persönlich...

Und wieso  fragst du nicht Cheatah was sein Stil hier soll?

Grüße
 Kurt

[Don P]

Hallo,

Und wieso  fragst du nicht Cheatah was sein Stil hier soll?

Mir wird's jetzt auch langweilig. Vor allem gehen mir deine rhetorischen Fragen auf den Wecker. Man schreibt sich die Finger Wund und redet doch nur gegen eine Wand. Benutze von mir aus Hashes und deine assoziative Arrays in JavaScript bis zum Abwinken, wenn du unbedingt Anfänger verwirren willst. Ich klink' mich jetzt aus.

Gruß, Don P

[KurtZ]

Hi

Ich klink' mich jetzt aus.

weiste das tragi(kom)ische ist das du mich selbst auf Crockford hingewiesen hast.

Ich halte diese Herdentriebargumente gewisser Vielposter für ziemlich dürftigen Ersatz für selbstständiges Denken. Insbesondere wenn ständig auch noch ständig sich wiedersprechende Sachen verlinkt werden, die man nicht mal selbst gelesen hat oder von selbstverständlichen Code fantasiert wird den sie nie geschrieben haben.

Na hauptsache halt, man hat was beigesteuert und die restliche Meute ist einverstanden, gell!?!

Bye
 Kurt

[Don P]

Hallo,

Das letzte Wort will ich dir jetzt doch nicht lassen ;-)

weiste das tragi(kom)ische ist das du mich selbst auf Crockford hingewiesen hast.

Ja hab' ich, und das ist gern geschehen.

Ich halte diese Herdentriebargumente gewisser Vielposter für ziemlich dürftigen Ersatz für selbstständiges Denken.

Es geht hier nicht um Herdentrieb. Falls du mich da einschließt, kennst du mich schlecht (im Gegenteil gehöre ich zu denen, die immer erst mal alles anzweifeln, aber ich lasse mich auch gern eines besseren belehren). Z.B. kenne ich niemanden, der hier Crockfords object-Funktion mal in irgendeiner Weise auch nur nur erwähnt hätte, außer mir selbst.

Was die assoziativen Arrays angeht, so ist der Begriff in SELFHTML zu recht weitgehend verschwunden, weil das in JavaScript nur Probleme gibt, wenn man Objekte einfach als solche bezeichnet. Anfänger verwenden z.B. gern ein new Array(), um ihm dann Eigenschaften zu verpassen und diese per array["bla"] anzusprechen, in der festen Meinung, sie hätten da ein schönes "assoziatives Array". Wenn es auch irgendwie stimmt, so macht das einfach wenig Sinn.

Du hast leider auf eine einfache Frage eines vermutlichen Anfängers als erstes unnötigerweise ausgerechnet vom assoziativen Array angefangen, und das auch noch mit Ausrufezeichen, als ob es besonders wichtig wäre, das so zu nennen bzw. als ob das ein feststehender Begriff in JavaScript wäre. Dem musste man einfach widersprechen. Hast zum Glück am Ende selber eingesehen, dass da noch Erklärungsbedarf bleibt.

Insbesondere wenn ständig auch noch ständig sich wiedersprechende Sachen verlinkt werden, die man nicht mal selbst gelesen hat oder von selbstverständlichen Code fantasiert wird den sie nie geschrieben haben.

Du weißt sehr gut was gemeint war, dass es nicht nur Fantasien sind und dass es im Grunde Wotklauberei ist, die aber in diesem Fall durchaus Sinn macht, um Missvertändnissen vorzubeugen, weil die "assoziativen Arrays" in JavaScript eben anders funktionieren, als man das von anderen Sprachen kennt.

Na hauptsache halt, man hat was beigesteuert und die restliche Meute ist einverstanden, gell!?!

Na Hauptsache halt, du hast mit deinem Wissen geprahlt, deine kontraproduktive Terminologie halbwegs verteidigt, natürlich vorzugsweise entgegen der Empfehlung der anderen, und sogar noch ein bisschen Recht gehabt, gelle.

Gruß, Don P

[KurtZ]

Hi

Was die assoziativen Arrays angeht, so ist der Begriff in SELFHTML zu recht weitgehend verschwunden, weil das in JavaScript nur Probleme gibt, wenn man Objekte einfach als solche bezeichnet. Anfänger verwenden z.B. gern ein new Array(), um ihm dann Eigenschaften zu verpassen und diese per array["bla"] anzusprechen, in der festen Meinung, sie hätten da ein schönes "assoziatives Array". Wenn es auch irgendwie stimmt, so macht das einfach wenig Sinn.

Langsam schwant mir auf welchem Trip ihr seit.

{...} ist ein literales new Object() kein new Array(), was Stefan Münz früher für Vermutungen reingeschrieben hat hat ja mir nix zu tun.

Auch habe ich nie Array() als assoziativ bezeichnet (leider kann man es so missbrauchen)

{...} ist eine "JS Form von Hash", der Anfänger der anfängt Object.prototype zu verändern und damit durchkommen möchte, den will ich sehen.

Mist, habe ich dir das letzte Wort genommen? ;)

Grüße
 Kurt

[Siechfred]

du wollest uns eine "Klasse" Hash() bauen, über die gefahrlos mit "for in" iteriert werden kann.

Es gibt bereits eine Klasse hash, das for..in kannst Du damit selber testen. Ansonsten sei exemplarisch auf Peter Seliger verwiesen.

Siechfred

[KurtZ]

Hi

Es gibt bereits eine Klasse hash, das for..in kannst Du damit selber testen.

Und hast du es selbst getestet? In der Doku steht nix von for-in Schleifen.

Ansonsten sei exemplarisch auf Peter Seliger verwiesen.

Danke,  vertritt meine Meinung! :)

(... was wahrscheinlich auch die Frage beantwortet ob du's getestet hast.)

Grüße
 Kurt

[KurtZ]

Hi

link:http://prototypejs.org/api/hash@title=hash], das for..in kannst Du damit selber testen.

Ts, ich erspare euch mal auszugeben was for in hier alles bei leeren Hashes liefert, hier wirds ne Postingquota geben.

Grüße
 Kurt

[Christoph]

Moin.

Ts, ich erspare euch mal auszugeben was for in hier alles bei leeren Hashes liefert, hier wirds ne Postingquota geben.

for...in ist ja auch nicht Mittel der Wahl, sondern each.

Christoph

[KurtZ]

ReMoin.

for...in ist ja auch nicht Mittel der Wahl, sondern each.

danke! (war mir bewusst :)

for-in kann halt nie 100% funktionieren, das als kill Kriterium gegen literale Objects zu nehmen ist halt (wortwörtlich) cheat-code.

Grüße
 Kurt

[Christoph]

Moin.

for-in kann halt nie 100% funktionieren,

Genau.

das als kill Kriterium gegen literale Objects zu nehmen ist halt (wortwörtlich) cheat-code.

Das will ja auch niemand. Aber gerade für Programmieranfänger ist die Aussage Objekt == assoziatives Array eventuell gefährlich, denn JavaScript-Objekte verhalten sich eben nicht wie z.B. PHP's assoziative Arrays. Deshalb sollte man solche Aussagen vermeiden bzw. auf die Problematik hinweisen.

Christoph

PS: Ich vermute mal, die beste Approximation an assoziative Arrays ohne zusätzliche Wrapper-Objekte sieht in etwa so aus (auf die Schnelle zusammengeschustert):

  
function foreach(obj, func) {  
 for(var prop in obj) {  
  if(obj.hasOwnProperty(prop) && obj[prop] !== undefined)  
   func.call(obj, prop, obj[prop]);  
 }  
}  
  
Object.prototype.set = function(key, value) {  
 this[key] = value;  
 return this;  
};  
Object.prototype.get = function(key) {  
 return this[key];  
};  
Object.prototype.remove = function(key) {  
 var value = this[key];  
 this[key] = undefined;  
 return value  
};  
  
var assoc = { foo : 'bar', spam : 'eggs' };  
assoc.set('answer', 42);  
assoc.remove('spam');  
  
foreach(assoc, function(key, value) {  
 document.writeln(key + ' : ' + value);  
});  

[LanX]

Hi Christoph

function foreach(obj, func) {
for(var prop in obj) {
  if(obj.hasOwnProperty(prop) && obj[prop] !== undefined)
   func.call(obj, prop, obj[prop]);
}
}

  
hmm ... man müsste sich das lambda func auch sparen können, ich denke ein Kostrukt mit while-Schleife könnte reichen:  
  
while ( obj.iterOwn(var) ) { BLOCK }  
  
var wird in iterOwn gesetzt, muss aber selbst ein Objekt sein (String() oder Number()) um bei reference übergeben zu werden.  
  
so könnte man auch die whiles schachteln  
  
~~~javascript
  
while (obj.iterOwn(var1) ) {  
   while (obj.iterOwn(var2) ) {  
   }  
}  

und vor allem break und continue nutzen

~~~javascript

Object.prototype.set = function(key, value) {
this[key] = value;
return this;
};

  
na das ist redundant, sorry!  
hash[key]=value reicht!  
  
 ~~~javascript
  

> Object.prototype.get = function(key) {  
>  return this[key];  
> };  

ich würds aber "own" nennen, und auf das redundante set verzichten.

(ich überleg gerade, ob man noch ein hasOwnProperty braucht ...)

~~~javascript

Object.prototype.remove = function(key) {
var value = this[key];
this[key] = undefined;
return value
};

  
warum nicht delete(hash.key)?  
  
  
Tschau  
 LanX  

[LanX]

Hi again

while ( obj.iterOwn(var) ) { BLOCK }

var wird in iterOwn gesetzt, muss aber selbst ein Objekt sein (String() oder Number()) um bei reference übergeben zu werden.

hab vergessen zu werwähnen das iterOwn auch undefined zurückgibt wenn die Schleife fertig ist.

Alernativ könnte man

while ( var=obj.iterOwn("LABEL") ) { BLOCK }

schreiben, label wäre dann ein primitiver Datentyp der hilft den Zähler zu identifizieren. Wenn man keien Schachtelungen hat und/oder weiß das die Schleife komplett durchlaufen wird, kann man auf LABEL verzichten.

So long
  LanX

PS: man sollte Anfängern gar nix von Object.prototype erzählen! Je weniger davon wissen umso ...

[Don P]

Hallo LanX,

Der Sinn deines Codes erschließt sich mir nicht ganz. Wenn ich richtig verstehe, geht es doch nur darum, die Eigenschaften/Methoden eines Objekts zu durchlaufen, ohne dabei die geerbten zu besuchen (vom Prototyp z.B.).

Dazu reicht doch folgende Funktion (ratet mal, von wem ich die habe ;):

  
var forOwn=function(o,f){for(var p in o){if(o.hasOwnProperty(p)){f(p,o[p]);}}};  
  
// Beispiel:  
  
Object.prototype.inherited = 'geerbt';                 // inherited wird von jedem Objekt geerbt  
  
var myObj = {a:1, b:2, c:3};                           // "assoziatives Array", *grummel* :-(  
  
for(var p in myObj) {alert(p + ": " + myObj[p]);}      // gibt auch inherited aus :-(  
  
forOwn(myObj, function (p,v) {alert(p + ": " + v);} ); // gibt nur a,b und c aus :-)

PS: man sollte Anfängern gar nix von Object.prototype erzählen! Je weniger davon wissen umso ...

Das stimmt, nützt aber nicht unbedingt etwas. Gerade Anfänger binden so gut wie jedes Script ein, dessen sie habhaft werden können. Wenn nur eines davon mit Object.prototype rummacht, haben sie evtl. ein Problem, das sie nicht lösen können ohne ein Wissen darum.

Gruß, Don P

[KurtZ]

Hi

Der Sinn deines Codes erschließt sich mir nicht ganz. Wenn ich richtig verstehe, geht es doch nur darum, die Eigenschaften/Methoden eines Objekts zu durchlaufen, ohne dabei die geerbten zu besuchen (vom Prototyp z.B.).
...
forOwn(myObj, function (p,v) {alert(p + ": " + v);} ); // gibt nur a,b und c aus :-)[/code]

Naja es wär schon schöner den gleichen Kontrollfluss wie bei einer direkten for-Schleife zu haben, statt eine anonyme Funktion übergebne zu müssen.
While () {} wär schon schick!

Wie er schon gesagt hat break und continue kannst du dann auch nicht mehr benutzen (naja Continue wär vielleicht ein  vorzeitiges Return in der Function und Break könnte man zusätzlich über den Rückgabecode des Returns  abbilden)

Aber du siehst ich muss hier für jedes gewünschte Verhalten einen Workaround bauen... wenn's aber mit while funktionieren täte, hätte man einen direkten Zugang.

PS: man sollte Anfängern gar nix von Object.prototype erzählen! Je weniger davon wissen umso ...

Das stimmt, nützt aber nicht unbedingt etwas. Gerade Anfänger binden so gut wie jedes Script ein, dessen sie habhaft werden können. Wenn nur eines davon mit Object.prototype rummacht, haben sie evtl. ein Problem, das sie nicht lösen können ohne ein Wissen darum.

Naja, wer unverstandenen Code einbindet, also sorry! Anfänger sollten begreifen das Object.prototype für "den Anfang" Tabu ist. (Dieser Thread zeigt deutlich das selbst "Profis" hier heftig schlingern) Mit Object.prototype verändere ich alle Objekte auch das Core, ich schaffe mir quasi einen neuen JS-Dialekt.

Und gute Bibliotheken wie portotype.js sind wenigstens konsequent genug Ersatzweise Hash() anzubieten. (allerdings auch nicht ohne Probleme)

Andersrum, wenn ich z.B. in Perl kritiklos iregdnwelche Module einbinde, brauch ich mich auch nicht zu wundern wenn meine Hashes nicht mehr funktionieren, wg einer tie-Bindung oder weil die Operatoren überladen wurden.

Deswegen behaupte ich aber auch nicht Perl kennt keine Hashes!

Grüße
 Kurt

[Don P]

Hallo,

Naja es wär schon schöner den gleichen Kontrollfluss wie bei einer direkten for-Schleife zu haben, statt eine anonyme Funktion übergebne zu müssen.

Sie muss nicht anonym sein, forOwn(myObject, myFunction); tut's natürlich auch. Wollte nur nicht zu viel Beispielcode schreiben. Ein bisschen SELF denken darf man noch ;-)

While () {} wär schon schick!

Kontrollfluss kann man ja dazubauen. Das ist nur mal die Grundfunktion. Ein bisschen SELF denken darf man noch (ach, das schub ich ja schon) ;-)

Wie er schon gesagt hat break und continue kannst du dann auch nicht mehr benutzen (naja Continue wär vielleicht ein  vorzeitiges Return in der Function und Break könnte man zusätzlich über den Rückgabecode des Returns  abbilden)

"er" schon wieder?

[...] Andersrum, wenn ich z.B. in Perl kritiklos iregdnwelche Module einbinde, brauch ich mich auch nicht zu wundern wenn meine Hashes nicht mehr funktionieren, wg einer tie-Bindung oder weil die Operatoren überladen wurden.

In Perl ist die Gefahr nicht so groß, weil nicht das nicht so populär ist. Jedes Kind meint aber JavaScript schreiben oder benutzen zu müssen, auch ohne die geringsten Programmierkenntnisse. Von JavaScript meinen deshalb viele, dass es gar keine richtige Programmiersprache sei, jedenfalls nicht richtig objektorientiert. Sogar Leute, die es eigentlich wissen müssten, schreiben hier im Forum Dinge wie in JavaScript sei keine richtige Vererbung  zu machen.

Gruß, Don P

[molily]

Hallo,

while ( obj.iterOwn(var) ) { BLOCK }

Aha. Und wie sieht die Implementierung von iterOwn aus, damit das so funktioniert?

Mathias

[Christoph]

Moin.

Aha. Und wie sieht die Implementierung von iterOwn aus, damit das so funktioniert?

Es lässt sich schon irgendwie drehen, dass das so oder so ähnlich funktioniert. Mal ein Beispiel:

  
function iterator(obj) {  
 var i = 0;  
 var props = [];  
  
 for(var prop in obj) {  
  if(obj.hasOwnProperty(prop))  
   props.push(prop);  
 }  
  
 return {  
  next : function() {  
   if(i < props.length) {  
    this.key = props[i];  
    this.value = obj[props[i]];  
    ++i;  
    return true;  
   }  
   else return false;  
  }  
 };  
}  
  
with(iterator(obj)) while(next()) {  
 document.writeln(key + ' : ' + value);  
}  

Das das natürlich totaler Käse ist und wesentlich weniger performant als

  
for(var prop in obj) {  
 if(obj.hasOwnProperty(prop))  
  document.writeln(prop + ' : ' + obj[prop]);  
}  

ist, ist klar ;)

Christoph

[KurtZ]

Hei Christoph,

Cooler Code, darauf with() so einzusetzen, um *dynamisch* ein Object zu generieren, dessen Properties next(),  key und value lokal sichtbar werden,  wär ich nie gekommen. :)

Insbesondere weil's momentan IN ist, with(){} zu verdammen!

Aus welcher Quelle hast du diese Technik?

Grüße
 Kurt

[Struppi]

Insbesondere weil's momentan IN ist, with(){} zu verdammen!

wie kommst du darauf?
Dir scheint nicht bekannt zu sien, das es offensichtlich vorgesehen war with als depricated zu kennzeichnen und alte Mozilla Versionen haben dies in der Feherkonsole auch immer schön gemeldet. Deshalb gab es wohl eine zeitlang eine Verunsicherung ob man with noch weiter verwenden soll/darf/kann. Aber soweit ich weiß wurde das wieder Rückgängig gemacht. Insofern ist deine Aussage falsch und dient lediglich der Provokation, ohne dass dir die Hintergründe klar sind, warum u.U. an manchen Stellen von with abgeraten wird oder wurde.

Struppi.

[Struppi]

Insbesondere weil's momentan IN ist, with(){} zu verdammen!

und hier zum nachlesen der Hinweis im MZ Developer Center:
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Statements:with

Note: Firefox 1.5 generates a warning when the 'with' statement is used: "deprecated with statement usage". This has been removed in Firefox 1.5.0.1 (bug 322430).

und du findest auch überall noch den Hinweis, dass with() deinen code stark verlangsamt, du solltest also with() verdammen, wenn es dir um performance geht und dich nicht von einer Mode leiten lassen.

Struppi.

[Christoph]

Moin.

Aus welcher Quelle hast du diese Technik?

Das ist auf eigenem Mist gewachsen. Mit with kann man halt so einiges anstellen, z.B.

  
function MyObject() {}  
MyObject.prototype.answer = 42;  
  
with({Object : MyObject})  
 document.writeln({}.answer); // 42  
  
document.writeln({}.answer); // undefined  
  
// funktioniert im IE nur mit new Object() statt {}  

Meine Idee war, dass man so eigentlich auch das Problem der JavaScript-Bibliotheken lösen könnte (was allerdings im IE ein Paar Probleme bereitet.

Ich habe an der Idee noch ein Bisschen weitergebastelt, momentan liegt sie aber wieder auf Eis...

Christoph

[Don P]

Hallo,

function MyObject() {}
MyObject.prototype.answer = 42;

with({Object : MyObject})
document.writeln({}.answer); // 42

document.writeln({}.answer); // undefined

// funktioniert im IE nur mit new Object() statt {}

  
Wow, sowas habe ich auch noch nie gesehen. Hätte "Object" für ein reserviertes Wort gehalten, ist es aber nicht. Seltsam, seltsam...  
  
Was dein Problem mit dem IE betrifft, so liegt das offenbar daran, dass dort gewisse Eigenschaften/Methoden von window.document als nicht iterabel gekennzeichnet sind (d.h. .propertyIsEnumerable()===false gilt), so wie z.B. die length-Eigenschaft eines Arrays und verschiedene andere in nativen JavaScript-Objekten. Nach allem, was ich darüber herausgefunden habe, gibt es keine Möglichkeit, propertyIsEnumerable von "außen" zu beeinflussen.  
  
Gruß, Don P  

[molily]

Hallo,

with({Object : MyObject})
document.writeln({}.answer); // 42

Super, du hast einen Exploit geschrieben. Das Überschreiben von Core-Konstruktoren ermöglicht Cross-Site Request Forgery mit JSON. Wenn du einen Browser findest, der das noch zulässt, dann gehört er auf den Müllhaufen der Geschichte. ;)

Mathias

[molily]

with({Object : MyObject})
document.writeln({}.answer); // 42

Super, du hast einen Exploit geschrieben.

Okay, so ganz stimmt das nicht, schließlich ist die Auswirkung auf den Block beschränkt und kann nicht so ohne weiteres externen Scripten eine andere andere Scope-Chain vorschreiben. Trotzdem wundert es mich, das Browser (IE hast du ausgenommen) das Verhalten von Literalen ändern, wenn man ein Objekt in der Scope-Chain zwischenschiebt. Andererseits sagt ECMAScript auch nur, {} erzeugt ein Objekt wie die Expression new Object() es tun würde, und für »Object« gelten dann die ganz normalen Regeln für die Auflösung von Bezeichnern.

Mathias

[KurtZ]

Kurtz gegrüßt

function MyObject() {}
MyObject.prototype.answer = 42;

with({Object : MyObject})
document.writeln({}.answer); // 42

document.writeln({}.answer); // undefined

// funktioniert im IE nur mit new Object() statt {}

  
Noch ein Aprilscherz ? \*fg\*  
  
Aber schon faszinierend, statt Object.prototype global zu verändern, könnte man eine lokale Umgebung schaffen, wo alle relevanten Sub-Konstruktoren die verändert werden sollen verändert werden, und dann wie gewohnt weiter machen.  
  
~~~javascript
  
with({Object : MyObject, Function: MyFunction, usw}) {  
// hier instanziere ich was etwas zusätzliches erben soll  
}  
//udn ab hier hab ich wieder Standardkonstruktoren inkl. "normaler" Hashes mit {}  

Hei, auch denkbar! Der Fakt das im IE {} lokal nicht funzt könnte man verkraften.

Meine Idee war, dass man so eigentlich auch das Problem der JavaScript-Bibliotheken lösen könnte (was allerdings im IE ein Paar Probleme bereitet.

hmm , was passiert wenn du document zuerst clonst?
also
 Func.prototype = new Object(document);

habe gerade keinen IE zum testen da...

Grüße
 Kurt

[KurtZ]

Kurtz gegrüßt

Aber schon faszinierend, statt Object.prototype global zu verändern, könnte man eine lokale Umgebung schaffen, wo alle relevanten Sub-Konstruktoren die verändert werden sollen verändert werden, und dann wie gewohnt weiter machen.

Herrje vergiss es, vielzu Umständlich um ein einfaches Ziel zu erreichen! Das ist wie mit dem Kopf voran in die Hose zu steigen...

Grüße
 Kurt

[Christoph]

Moin.

Herrje vergiss es, vielzu Umständlich um ein einfaches Ziel zu erreichen! Das ist wie mit dem Kopf voran in die Hose zu steigen...

Daher ja auch die Idee, eine Bibliothek zu schreiben, die das Erstellen eigener Bibliotheken erleichtert. Schau dir doch mal das Beispiel an (lib1, lib2, lib3)...

Christoph

[KurtZ]

Kurtz gegrüßt

Daher ja auch die Idee, eine Bibliothek zu schreiben, die das Erstellen eigener Bibliotheken erleichtert. Schau dir doch mal das Beispiel an (lib1, lib2, lib3)...

Sorry, gerade wenig Zeit, aber kennst du den Vorschlag aus dem O'Reilly Definitiv Guide zu Packages?

hat
  Func.prototype = new Object(document);
im IE was gebracht?

Grüße
 Kurt

[molily]

Hallo,

hat
  Func.prototype = new Object(document);
im IE was gebracht?

new Object(document) === document

Mathias

[LanX²]

Hi

witziger Code,

with(iterator(obj)) while(next()) {
document.writeln(key + ' : ' + value);
}

  
leider auch nicht viel kürzer als mit Filter. Schade :(  
  

> Das das natürlich totaler Käse ist und wesentlich weniger performant als  
> ~~~javascript
  

> for(var prop in obj) {  
>  if(obj.hasOwnProperty(prop))  
>   document.writeln(prop + ' : ' + obj[prop]);  
> }  
> 

hast du's denn ausgemessen??? Der Overhead liegt IMHO nur im Aufbau des Key-Arrays (da kommt man leider kaum umhin)!

Auch for-in baut intern erst eine Liste auf die abgearbeitet wird.

So long
 LanX

[LanX²]

Hi

while ( obj.iterOwn(var) ) { BLOCK }

Aha. Und wie sieht die Implementierung von iterOwn aus, damit das so funktioniert?

Aha? Und was genau ist dein Problem dabei?

Als globale Funktion ist das nur Handwerk

while ( iterOwn(obj,key) ) { BLOCK }

Das zusätzlich als Methode in Object.prototype zu verankern sollte optional und im Ermessen des Users liegen. Die notwendigkeit ergibt sich IMHO erst wenn jemand sowieso dort rumpfuscht.

while ( obj.iterOwn(key) ) { BLOCK }

Gegenfrage weiter unten sprichst du glaube ich davon den Object Konstruktor zu verändern, könntest du das für uns präzisieren?

Gruß
  LanX

[molily]

Hallo,

Als globale Funktion ist das nur Handwerk
while ( iterOwn(obj,key) ) { BLOCK }

Eigenschaften kann man mit for-in durchlaufen, aber eine for-in-Schleife nicht nach einem Durchlauf abbrechen, um beim nächsten Durchlauf an dieser Stelle weiterzumachen. Das kann man natürlich, wenn man irgendwo die letzte Property speichert, nur wo will man sie sinnvollerweise speichern? Außerdem, wie setzt die iter-Funktion die lokale Variable? Es ginge höchstens while (wert = iter(obj)) oder so etwas.

Christophs umständliches Beispiel mit with löst das natürlich, aber sieht ganz anders aus als obiger einfacher Code.

Gegenfrage weiter unten sprichst du glaube ich davon den Object Konstruktor zu verändern, könntest du das für uns präzisieren?

function Object () {}

Mathias

[LanX²]

Hallo,

Als globale Funktion ist das nur Handwerk
while ( iterOwn(obj,key) ) { BLOCK }

Eigenschaften kann man mit for-in durchlaufen, aber eine for-in-Schleife nicht nach einem Durchlauf abbrechen, um beim nächsten Durchlauf an dieser Stelle weiterzumachen. Das kann man natürlich, wenn man irgendwo die letzte Property speichert, nur wo will man sie sinnvollerweise speichern? Außerdem, wie setzt die iter-Funktion die lokale Variable? Es ginge höchstens while (wert = iter(obj)) oder so etwas.

Wie gesagt, die Laufvariable ist Träger der Info, muss dafür aber vorweg als Objekt initialisiert werden.

Das wird vielleicht an etwas Code klarer:

<html><body>
<h3> nextOwn v0.2 </h3>
<pre>

<script>
//~~~javascript

function echo(str) {
  document.writeln(str);
}

function keys (obj) {
  a=new Array();
  for (key in obj)
     if(obj.hasOwnProperty(key)) {
        a.push(key);
     };
  return a;
}

function nextOwn( obj,key) {
  if (! key.hash || key.hash != obj ) {
    /* init /
    key.hash=obj;
    key.array=keys(obj);
    key.toString=function () {
      return this.array[this.idx]
    }
    key.key="";
    key.value="";
    key.idx=0;
  } else {
    / next */
    key.idx++;
  }

with (key) {
    if ( idx<array.length ) {
      key=array[idx];
      value=hash[key];
      return true;
    }
    else {
      delete hash ;
      return false;
    }
  }
}

/*
 *    Test
 */

var hash={a:"A",b:"B",c:"C",d:"D"};
var hash2={c:"C",d:"D"};

var j={}; // Laufvariable initialisieren

while( nextOwn( hash, j ) ){
  echo( j +":"+hash[j] );
  echo( j.idx+" > "+j.key +":"+ j.value +" ["+j.array+"]");
 };

echo("<hr>")

while( nextOwn( hash, j ) ){
  echo( j +":"+hash[j] );
  echo( j.idx+" > "+j.key +":"+ j.value +" ["+j.array+"]");
 };

echo("<hr>")

while( nextOwn(hash2, j) ){
  echo( j +":"+hash[j] );
  echo( j.idx+" > "+j.key +":"+ j.value +" ["+j.array+"]");
 };

//

  
</script>  
</pre>  
</body></html>  
  
Zufrieden bin ich nicht, aber bevor sich die Diskussion länger hinzieht mal diese Approximation. Ein key={} vorm while ist IMHO immernoch die eleganteste der bisherigen Lösungen.  
  
Eine Alternative wäre, wie auch bereits gesagt, bei jeder Schleife einen eindeutiges "Label" als String zu übergeben. (analog zu den break/continue Labels) um die Schleife eindeutig auszuzeichnen.  
  
while ( key=nextOwn(hash,"label") ) {}  
  
Aber dann erscheint mir die erste Lösung mit key={} vorweg noch angenehmer!  
  
  

> > Gegenfrage weiter unten sprichst du glaube ich davon den Object Konstruktor zu verändern, könntest du das für uns präzisieren?  
>   
> function Object () {}  
  
Ja klar, so weit waren wir auch schon, aber welchen Vorteil es bringt, um .begetObject zu realisieren hast du nicht erklärt. Ich sehe keinen.  
  
So long  
  LanX

[molily]

Hallo,

Ja klar, so weit waren wir auch schon, aber welchen Vorteil es bringt, um .begetObject zu realisieren hast du nicht erklärt. Ich sehe keinen.

Wo habe ich das behauptet?
Ich hatte mal gesagt, dass man begetObject usw. auch als Methode der Konstruktorfunktion window.Object statt als Methode ihres Prototypen speichern kann. So machen es viele Bibliotheken wie Prototype.js mit ähnlichen Methoden.

Mathias

[KurtZ]

Kurtz gegrüßt

So machen es viele Bibliotheken wie Prototype.js mit ähnlichen Methoden.

Aha! das dürfte erklären wieso es dort eine extra Hashklasse geben muss.

Grüße
 Kurt

[molily]

Hallo,

Aha! das dürfte erklären wieso es dort eine extra Hashklasse geben muss.

Was hat das miteinander zu tun?

Mathias

[KurtZ]

Kurtz gegrüßt

Aha! das dürfte erklären wieso es dort eine extra Hashklasse geben muss.

Was hat das miteinander zu tun?

Ächz, hab mir jetzt die Mühe gemacht genauer bei prototype.js nachzugucken um diesen Dialog nachzuvollziehen.

Also würde prototype.js wie du schriebst die

Methode der Konstruktorfunktion window.Object

sowie
function Object() {}

verändern, also sowas

function Object() {
  this.beget=function(){}
}

dann würde a={} und b=a.beget() möglich sein, und man bräuchte folglich einen Ersatz für Hashes.

Prototype.js hingegen erweitert nicht die Object()-Funktion sondern das assoziierte Object()-Objekt um es als "Namespace" zu nutzen.

Object.beget=function(){}

was aber im Zusammenhang mit vererbten Methoden nicht wirklich hilft

a={} hätte keine Methode beget, und man müsste b=Object.beget(a) schreiben, was keinen wirklichen OOP Mehrwert hätte außer nem aufgeräumten Namespace.

Grüße
 Kurt

[KurtZ]

Kurtz gegrüßt

auch ein netter code :)

Wie gesagt, die Laufvariable ist Träger der Info, muss dafür aber vorweg als Objekt initialisiert werden.

dann wäre diese Schreibweise expliziter , oder?

  
for ( i={}; nextOwn( hash, i ); ){  
  echo( i +":"+hash[i] );  
 }  
  

Grüße
 Kurt

[LanX²]

Hallo Kurt,

dann wäre diese Schreibweise expliziter , oder?

for ( i={}; nextOwn( hash, i ); ){
  echo( i +":"+hash[i] );
}

  
DANKE! :)  
  
Du bringst mich auf den richtigen Pfad wie das Interface vernünftig auszusehen hat, so lösen sich nämlich dann alle Label-Probleme, das DRY-Prinzip wird (fast) erfüllt und der Code ist IMHO schlank und intuitiv lesbar!  
  
~~~javascript
  
 for ( i=ownKey(hash) ; i.next(); ) {  
   echo( i +":"+hash[i] );  
  }  
  
//oder  
j=ownKey(hash);  
  
while ( j.next() ) {  
   echo( j +":"+hash[j] );  
}  
  
  

später mehr!

so long
  LanX

[molily]

Hallo,

PS: Ich vermute mal, die beste Approximation an assoziative Arrays ohne zusätzliche Wrapper-Objekte sieht in etwa so aus

Wieso sollte man das tun?

foreach(assoc, function(key, value) {
document.writeln(key + ' : ' + value);
});

Sowas kann ich mir auch ohne Object.prototype bauen. Wozu brauche ich set/get/remove, wenn ich weiß, was Objekte sind?

Mathias

[LanX]

Hi

Sowas kann ich mir auch ohne Object.prototype bauen. Wozu brauche ich set/get/remove, wenn ich weiß, was Objekte sind?

um es Anfängern zu vereinfachen fehlerfrei mit Hashes zu arbeiten.

Tschau
 LanX

[molily]

Hallo,

um es Anfängern zu vereinfachen fehlerfrei mit Hashes zu arbeiten.

Nicht das grundlegendste JavaScript-Konzept verstehen, aber JavaScript schreiben und dann eine Abstraktion nutzen, die einen davon abhält, eben jenes zu erlernen. Ja, klingt plausibel.

Mathias

[Christoph]

Moin.

Sowas kann ich mir auch ohne Object.prototype bauen. Wozu brauche ich set/get/remove, wenn ich weiß, was Objekte sind?

Um zu testen, ob die foreach-Schleife die Eigenschaften des Prototyps durchläuft ;)

Christoph

[Siechfred]

Es gibt bereits eine Klasse hash, das for..in kannst Du damit selber testen.
Und hast du es selbst getestet? In der Doku steht nix von for-in Schleifen.

Du hast von for..in angefangen, nicht ich. Ich wollte Dich lediglich auf die bereits existierende hash-Klasse aufmerksam machen, mehr nicht. Zudem schreibt Peter ausdrücklich und wohlbegründet, warum es in JS keine assoziativen Arrays gibt, sondern dass es sich dabei um einfache Objekte handelt.

Lieber KurtZ, ich weiß wirklich nicht wo Dein Problem liegt. Du beißt verbal um Dich, und das nicht zum ersten Mal. Ich fände es einer zukünftigen Diskussion mit Dir förderlich, wenn Du Dich ein bisschen zurücknehmen könntest, bevor Du jeden angehst, der nicht Deiner Meinung ist bzw. der Deine Auffassung nicht stützt. Bis dahin werde ich persönlich mir sorgfältig überlegen, ob und wie ich auf Deine Postings antworte.

Siechfred

[KurtZ]

Kurtz gegrüßt

Und hast du es selbst getestet? In der Doku steht nix von for-in Schleifen.

Du hast von for..in angefangen, nicht ich.

schau mal da: https://forum.selfhtml.org/?t=169127&m=1104127

Ich wollte Dich lediglich auf die bereits existierende hash-Klasse aufmerksam machen, mehr nicht.

Danke, sehr interessant. Aber als Gegenargument taugt es wenig. Erst wer Object.prototype anfasst braucht dieses Hash() als Workaround.

Zudem schreibt Peter ausdrücklich und wohlbegründet, warum es in JS keine assoziativen Arrays gibt, sondern dass es sich dabei um einfache Objekte handelt.

Hilf mir, wo genau?

[quote]gleichzeitig moechte
   ich aber einige langlebige missverstaendnisse aus
   dem weg raeumen:

"in javascript gibt es keine 'assoziativen arrays'!"
[/quote]

Er macht exakt das gleiche wie ich, nur dass ich genauer auf die Stolperfallen eingehe. https://forum.selfhtml.org/?t=169127&m=1104262

Lieber KurtZ, ich weiß wirklich nicht wo Dein Problem liegt. Du beißt verbal um Dich, und das nicht zum ersten Mal.

Lieber Siechfred, gehen wir in die Analyse:

Es hat wohl mal eine Zeit gegeben wo Selfhtml propagiert hat Array() als Hash zu misbrauchen, was leider viele Probleme verursacht.

P. Seliger geht genau *darauf* ein (udn fährt meine Linie)!

Nach seinem Posting hat sich bei den hiesigen "Kennern" wohl dann der Pawlowsche Reflex ausgebildet beim Textpattern "Assoziatives Array" unermüdlich zu bellen und erst dann zu denken wenn das Gegenüber konsequent scharf zurückbellt.

Da ihr mir aber mittlerweile zuhört:

Der Fehler ist nicht Object() (nicht Array()) als Hash zu nutzen, (das ist absichtlich so designt), sondern *gleichzeitig* for-in und Object.prototype zu nutzen.

(for-in ist eine Art erweiterbares foreach, DARAUF muss man hinweisen. Es ist in anderen Sprachen auch nicht ungewöhnlich, dass man fundamentales Verhalten redefinieren kann, aber das macht halt kein Anfänger)

Wenn man aber Object.prototype erst mal sinnlos verseucht hat, so wie Cheatah das tut, dann wird es aber NIE ein Hashkonstrukt geben können der mit for-in funktioniert. Da beisst sich der Pawlow peinlichst in den Schwanz.

Also entweder oder, und verklickert bitte den Anfängern keine Gerüchte.

In noch einfacheren Worten:

Wer die Gravitation ändert, braucht sich über die Beulen am Kopf nicht zu wundern. Deswegen braucht man aber nicht zu behaupten Springen sei unmöglich.

Ich fände es einer zukünftigen Diskussion mit Dir förderlich, wenn Du Dich ein bisschen zurücknehmen könntest, bevor Du jeden angehst, der nicht Deiner Meinung ist bzw. der Deine Auffassung nicht stützt. Bis dahin werde ich persönlich mir sorgfältig überlegen, ob und wie ich auf Deine Postings antworte. Bis dahin werde ich persönlich mir sorgfältig überlegen, ob und wie ich auf Deine Postings antworte.

Das wäre schön, und les dir bitte das Posting von P.Seliger mal *richtig* durch.

Ich habe bei aller Schärfe nie Probleme gehabt zuzugeben wenn ich unrecht war. Hier hingegen versuchen sich einige krampfhaft zu rechtfertigen, vielleicht um ihren Status als Kenner nicht einzubüssen?

Da geht mir die Hutkrempe hoch!

Frage: Wieso tritt dieses Problem mit den Honoratioren von Perl-community.de nicht auf?

Grüße
 Kurt

[Struppi]

Zudem schreibt Peter ausdrücklich und wohlbegründet, warum es in JS keine assoziativen Arrays gibt, sondern dass es sich dabei um einfache Objekte handelt.

Hilf mir, wo genau?

[quote]gleichzeitig moechte
   ich aber einige langlebige missverstaendnisse aus
   dem weg raeumen:

"in javascript gibt es keine 'assoziativen arrays'!"
[/quote]

Er meint dort das Mißverständniss, dass es AAs in JS gibt und zwar genau aus dem Grund den du hier mehrfach nennst. Es gibt keine Möglichkeit mit 100% Sicherheit über for (was den Ausdruck Array erklären könnte) in Objekteigenschaft zu iterieren, da diese mit prototype erweitert werden können. Ein zuverlässiges AA müßte man sich selbst basteln.

und mir ist auch nicht klar, warum du so reagierst. Du möchtest über ein Thema diskutieren und schmeisst mit Diffamierungen um dich, als ob es um das Ende des Abendlandes geht. Es geht hier offensichtlich um einen Standpunkt, den man mit verschiededenen Sichtweisen sehen kann, und das für mich erstaunliche ist, es geht lediglich um einen Begriff. Jeder der hier mitdiskutiert, weiß um die Abläufe, darüber gibt es keinerlei Meinugsverschiedenheiten. Jeder weiß dass ein Objekt wie ein Hash verwendet werden kann, es dabei aber zu Schwierigkeiten kommen kann, deshalb ist es für die eine Gruppe problematisch von einem assoziativen Array zu sprechen, da es eine Funktionalität vorrausetzt die nicht existiert, für die andere spielt das erstmal keine Rolle so lange man nicht Objekt.prototype verwendet (du sprichst von einem Tabu).

In der Erklärung wikipedia taucht JS nicht auf, was in meinem augen auch logisch ist, da ein Object in JS eben mit prototype Eigenschaften erbt, die eben nicht "eine für die Programmierer nachvollziehbare Verbindung zwischen Schlüssel und Datenwert" herstellt.

Struppi.

[Don P]

Hallo,

Jeder weiß dass ein Objekt wie ein Hash verwendet werden kann, es dabei aber zu Schwierigkeiten kommen kann, deshalb ist es für die eine Gruppe problematisch von einem assoziativen Array zu sprechen, da es eine Funktionalität vorrausetzt die nicht existiert, für die andere spielt das erstmal keine Rolle so lange man nicht Objekt.prototype verwendet (du sprichst von einem Tabu).

Genau, Kurt Z muss Object.prototype tabuisieren, weil seine ganze Argumentation sonst wie ein Kartenhaus zusammenfällt, was natürlich nicht sein  darf, da er immer recht behält, notfalls mit persönlichen Angriffen, und immer das letzte Wort haben muss (wirst du gleich wieder sehen, wetten?). Er hat mittlerweile für mich etwas von einem Troll, abgesehen davon, dass etwas mehr Ahnung zu haben scheint, als das Trolle üblicherweise haben.

Da können alle mit Engelszungen argumentieren, soviel sie wollen. Das wird dann einfach als Herdentrieb, Knacks im Ego, Pawlowsches-Hunde-Psychodingsda oder was immer abgetan.

Der arme Kerl, wahrscheinlich braucht er Hilfe. Aber sicher nicht in JavaScript, das hat er ja anscheinend selber schon im Mutterleib erfunden. *SCNR*

Gruß, Don P (reinrassiger Pawlow-Hund ;-)

[KurtZ]

Hi Struppi

Er meint dort das Mißverständniss, dass es AAs in JS gibt und zwar genau aus dem Grund den du hier mehrfach nennst.

auch du mein Feund lies es bitte komplett, insbesondere den Teil ab "deswegen bitte so":

[quote]
   var simpleObj = new Object();
...
   var simpleObj = {}; // {} literal fuer new Object();
...
   var simpleObj = {
     propName01: "something",
     propName02: "something else"
   };

...
   var simpleObj = {
     "propName01": "something",
     "propName02": "something else"
   };
[/quote]

wie auch immer ich betreibe keine P.Seliger Exegese, der Mann ist auch kein Brendan Eich.

und mir ist auch nicht klar, warum du so reagierst. Du möchtest über ein Thema diskutieren und schmeisst mit Diffamierungen um dich, als ob es um das Ende des Abendlandes geht.

Daniel bringt es auf den Punkt:
https://forum.selfhtml.org/?t=169127&m=1104573

Du, ich habe nur mit Cheatahs Worten geantwortet, er scheint hier ein "Anpiss"-Privileg zu genießen, die Antwort aber wie er hingegen Hashes in JS besser realisiert ist, bleibt er uns natürlich schuldig, schließlich ist er ja der King der zynischen Einzeiler!

Es geht hier offensichtlich um einen Standpunkt, den man mit verschiededenen Sichtweisen sehen kann, und das für mich erstaunliche ist, es geht lediglich um einen Begriff.

Nein, es dreht sich darum wie hier mit Rhetorik agiert wird, statt nachprüfbare Argumente zu liefern.

In der Erklärung wikipedia taucht JS nicht auf, was in meinem augen auch logisch ist, da ein Object in JS eben mit prototype Eigenschaften erbt, die eben nicht "eine für die Programmierer nachvollziehbare Verbindung zwischen Schlüssel und Datenwert" herstellt.

WP ist doch wohl jetzt kein Argument, oder?

What ever, solange mir keiner eine bessere Programmierpraxis für den Fall "Object.prototype unverändert" liefert, propagiere ich Object() als Hash!

Desweitern liefert hasOwnProperty eine 100% verlässliche Methode in ALLLEN Fällen fehlerfrei auf das Hash zuzugreifen.

Man zeige mir bitte Code der sonst scheitert und verzichte auf Worthülsen.

Ich verklicker ja auch nicht meinen Kiddies dass sie nur mit Gasmaske atmen dürfen, weil jemand ABC-Waffen schmeißen könnte. Erst wenn ich nach Israel.js ziehen wärs was anderes.

... seufz ... es reicht ..

Weist du ich bemühe mich immer fundierte Sachen zu posten, wenn ich aber gegen Berufssarkasten und Blindverlinker argumentieren muss, vergeht mir die Lust, weil ich viel mehr Arbeit reinstecken muss als Billigposter.

Grüße
 Kurt

[Struppi]

Er meint dort das Mißverständniss, dass es AAs in JS gibt und zwar genau aus dem Grund den du hier mehrfach nennst.

auch du mein Feund lies es bitte komplett, insbesondere den Teil ab "deswegen bitte so":

Ich bin nicht dein freund und ich habe das Posting von Peter gelesen und falls du gesehen hast war ich an dem Thread ebenfalls beteiligt. aber du machst hier was ganz fieses Sätze aus dem Kontext reissen, da steht nämlich:

...

missbrauchen den Array-konstruktor, da hier
   offensichtlich "nur" ein einfaches objekt mit ein
   paar eigenschaften erzeugt werden soll - weder die
   eigenschaft "length" noch die array-methoden, ueber
   die ein array-objekt verfuegen kann, werden von einer
   solchen chimaere jemals benoetigt - deswegen bitte so:

What ever, solange mir keiner eine bessere Programmierpraxis für den Fall "Object.prototype unverändert" liefert, propagiere ich Object() als Hash!

Desweitern liefert hasOwnProperty eine 100% verlässliche Methode in ALLLEN Fällen fehlerfrei auf das Hash zuzugreifen.

Sehr schön, wir fassen zusammen, ein Object ist ein Hash.
Es muss aber beachtet werde, dass wenn die Möglichkeit besteht, dass Object.prototype manipuliert wurde, in einer for in Schleife zuvor mittels hasOwnProperty geprüft wird ob der Schlüssel tasächlich ein Schlüssel ist.

Ich kenne keine offizielle Erklärung wie ein Hash 100% exakt definiert wird,  aber warum nicht.

Ich verklicker ja auch nicht meinen Kiddies dass sie nur mit Gasmaske atmen dürfen, weil jemand ABC-Waffen schmeißen könnte. Erst wenn ich nach Israel.js ziehen wärs was anderes.

das ist vernüftig, wobei ich hier Ecken kenne wo ich mir manchmal eine Wünsche, z.b. an der Abfahrt Mainz-Mombach

Struppi.

[KurtZ]

Ich bin nicht dein freund und ich habe das Posting von Peter gelesen und falls du gesehen hast war ich an dem Thread ebenfalls beteiligt. aber du machst hier was ganz fieses Sätze aus dem Kontext reissen, da steht nämlich:

...
       missbrauchen den Array-konstruktor, da hier
   offensichtlich "nur" ein einfaches objekt mit ein
   paar eigenschaften erzeugt werden soll - weder die
   eigenschaft "length" noch die array-methoden, ueber
   die ein array-objekt verfuegen kann, werden von einer
   solchen chimaere jemals benoetigt - deswegen bitte so:

Bitte???? Mein Nichtfreund ich zitiere sauber! Ich hebe nur die Stellen hervor die ihr ständig zu überlesen gedenkt. Ich habe NIX aus dem Kontext gerissen udn sauber gekürzt!

So und jetzt erwarte ich eine Präzisierung  was an meinem Quote "fies" war!!!

In deinem neuen Quote gehts um Array(). Ich habe NIE von Array() als AA gesprochen sondern Object() genannt.

Was soll das? Und wer verfehlt hier "fies" das Thema ?

[Struppi]

Bitte???? Mein Nichtfreund ich zitiere sauber! Ich hebe nur die Stellen hervor die ihr ständig zu überlesen gedenkt. Ich habe NIX aus dem Kontext gerissen udn sauber gekürzt!

So und jetzt erwarte ich eine Präzisierung  was an meinem Quote "fies" war!!!

In deinem neuen Quote gehts um Array(). Ich habe NIE von Array() als AA gesprochen sondern Object() genannt.

Exakt, jetzt hast du es verstanden, es ging in dem Thread um Array()

Peter sagt:

"in javascript gibt es keine 'assoziativen arrays'!"

"jedes dennoch im javascript-kontext auftauchende
    'assoziative array' wurde brutal vergewaltigt!"

_das_ist_so_ : warum ist das so?

konstrukte der art ...

var assocArr = new Arr();
   assocArr["keyName01"] = "something";
   assocArr["keyName02"] = "something else";
   ...
        missbrauchen den Array-konstruktor, da hier
   offensichtlich "nur" ein einfaches objekt mit ein
   paar eigenschaften erzeugt werden soll - weder die
   eigenschaft "length" noch die array-methoden, ueber
   die ein array-objekt verfuegen kann, werden von einer
   solchen chimaere jemals benoetigt - deswegen bitte so:

var simpleObj = new Object();

Es gibt keine assoziativen Arrays, sondern nur simple Objekte, die manche unter gewissen Bedingungen Hash nennen.

Struppi.

[KurtZ]

Kurtz gegrüßt

toll jetzt hast du *definitiv* aus dem Kontext gerissen (du fieser du)

er bezeichnet

"in javascript gibt es keine 'assoziativen arrays'!"

als Missverständnis (schlag nach!) und wird sogar konkret

solchen chimaere jemals benoetigt - deswegen bitte so:

var simpleObj = new Object();

Vielleicht (?) hat ers ja anders gemeint, dann kann er sich aber wohl nicht sauber ausdrücken.

Was man aber  an einem "deswegen bitte so:" + *meiner*Konstruktion* missinterpretierst ist mir schleierhaft,...

... und möchte ich jetzt nicht weiter ausdiskutieren, welche Autorität sollte P.Seliger auch für mich haben, insbesondere wenn er sich selbst nach eurer Meinung auch nicht präzise ausdrücken kann?

Interessant ist dass dieses deutungsreiche Post (das sich im wesentlichen um ein anderes Thema dreht - Array() als AA!)  als Argument herhalten sollte, dass ich mich falsch in meinen Posts ausdrücke!

Erkennst du die Farce in diesem Dialog? Du wirst verstehen dass ich ab hier nicht mehr mitspiele, das ist Halma mit Zusatzjoker!

tschüss
   Kurt

[Christoph]

Moin.

Es gibt keine assoziativen Arrays, sondern nur simple Objekte, die manche unter gewissen Bedingungen Hash nennen.

Ähem... - der Begriff 'Hash' ist jedoch je nach Kontext:

1. Kurzform für die (klar bestimmte) Datenstruktur Hashtabelle (mit der sich assoziative Arrays und auch JS-Objekte realisieren lassen)

2. Synonym für den (weniger klar bestimmten) Datentyp 'assoziatives Array', der sich in diversen Programmiersprachen (PHP, Perl) findet

Deine Aussage ergibt in meinen Augen also wenig bis gar keinen Sinn ;)

Christoph

[Struppi]

Es gibt keine assoziativen Arrays, sondern nur simple Objekte, die manche unter gewissen Bedingungen Hash nennen.

Ähem... - der Begriff 'Hash' ist jedoch je nach Kontext:

1. Kurzform für die (klar bestimmte) Datenstruktur Hashtabelle (mit der sich assoziative Arrays und auch JS-Objekte realisieren lassen)

2. Synonym für den (weniger klar bestimmten) Datentyp 'assoziatives Array', der sich in diversen Programmiersprachen (PHP, Perl) findet

So - hier krieg ich langsam Probleme mit der Bedeutung. Für mich war klar, dass Kurt AA und Hash synonym verwendet, aber in den beiden oben genannten Sprachen gibt es eben AAs oder HASH als Datentypen, die spezielle Funktionen für diesen Datentyp bereitstellen um auf die Daten zuzugreifen, in JS gibt es nur Funktionen um ein Object überhaupt so nutzen zu können (ausser der for in Schleife). Fakt ist, es kann so genutzt werden, weil es diese mittlerweile gibt, aber reicht das aus um ein Object dann als AA oder Hash zu bzeichnen?

Deine Aussage ergibt in meinen Augen also wenig bis gar keinen Sinn ;)

tut mir leid für das Mißverständniss, in dem Satz ging es mir in erster Linie um "gewisse Bedingungen", daher hab da gar nicht lange drüber nachgedacht.

Struppi.

[KurtZ]

Kurtz gegrüßt

1. Kurzform für die (klar bestimmte) Datenstruktur Hashtabelle (mit der sich assoziative Arrays und auch JS-Objekte realisieren lassen)

2. Synonym für den (weniger klar bestimmten) Datentyp 'assoziatives Array', der sich in diversen Programmiersprachen (PHP, Perl) findet

du verwirrst mich... also

1. wenn man WP glauben darf ist AA der Standardbegriff für das was in verschiedenen Sprachen Hash, Hashmap, Hashtabelle, Directory, usw genannt wird (oder so).

2. Als "typeof" eines Objektes in JS bekommt man "object",  der entspricht aber in der Semantik genau dem Datentyp  AA mit gewissen Defaulkeys. (type "function" jetzt mal außen vor)

3. Um die Datenstruktur AA in JS zu realisieren, kann man den Datentyp "object" deswegen 1:1 heranziehen, muss aber syntaktischen Aufwand betreiben, weil dezidierte AA-Operatoren teilweise fehlen oder umständlich umzusetzen sind (sprich hasOwnProperty).

4. Aus Bequemlichkeit bevorzugen viele syntaktische Einfachheit und entscheiden statt dessen die Defaultbelegungen zu umgehen (ähnlich den *viel* häufigeren Spezialvariablen in Perl also $_, $a, $b, $0 ,usw...) oder Sonderzubehandeln (Verzicht auf Object.prototype)

Ich bevorzuge den Terminus Hash!

(tatsächlich gibts wohl diverse Implementierungen für AA von denen die mit Hashfunktion nur eine Variante darstellt, aber die Implementierung ist ja Transparent)

1. Weil er kürzer ist.
2. Weil in JS dann Verwechslungen mit Array() zu nahe liegen.

My POV, bitte korrigiert mich.

Grüße
 Kurt

[KurtZ]

Hi

2. Als "typeof" eines Objektes in JS bekommt man "object",  der entspricht aber in der Semantik genau dem Datentyp  AA mit gewissen Defaulkeys. (type "function" jetzt mal außen vor)

muss mich jetzt selbst ergänzen, ein object kann auch unsichtbare Properties haben, wie z.B. __proto__ das im Mozilla direkt sichtbar ist, in anderen Browsern hingegen nicht.

Aber ich schätze in der Implementierung von Perlhashes gibts auch versteckte Attribute...

bye
 Kurt

[Christoph]

Moin.

du verwirrst mich...

Mal sehen, ob man das nicht etwas entwirren kann ;)

1. wenn man WP glauben darf ist AA der Standardbegriff für das was in verschiedenen Sprachen Hash, Hashmap, Hashtabelle, Directory, usw genannt wird (oder so).

Wikipedia, EN:
An associative array (also associative container, map, mapping, hash, dictionary, finite map, lookup table, and in query-processing an index or index file) [...]

Man beachte das Fehlen des Begriffs 'hash table'. Ich verwende diesen Begriff in seiner engeren Bedeutung, d.h. einer bestimmten Implementierung eines assoziativen Arrays mit einer Hash-Funktion, die einem Schlüssel eine natürliche Zahl zuordnet, die als Index eines Arrays zum Auffinden des Werts benutzt wird (der Mechanismus zur Auflösung von Kollisionen bleib unspezifiziert - separate/coalesced chaining, linear/quadratic probing, double hashing, ...)

2. Als "typeof" eines Objektes in JS bekommt man "object",  der entspricht aber in der Semantik genau dem Datentyp  AA mit gewissen Defaulkeys. (type "function" jetzt mal außen vor)

Ja. In Javascript erbt _alles_ von Object.prototype (auch Funktionen). Das führt ja gerade zu den bereits diskutierten Problemen. Laut MDC wäre es theretisch möglich, dieses Verhalten per

  
 obj.__defineSetter__('__proto__', function(value) {  
  this['__proto__'] = value;  
 });  
 obj['__proto__'] = undefined;  

zu unterbinden. Leider wirft die Laufzeitumgebung beim setzen eines Setters für __proto__ einen Fehler.

3. Um die Datenstruktur AA in JS zu realisieren, kann man den Datentyp "object" deswegen 1:1 heranziehen, muss aber syntaktischen Aufwand betreiben, weil dezidierte AA-Operatoren teilweise fehlen oder umständlich umzusetzen sind (sprich hasOwnProperty).

Ja. Wobei ich die Abfrage von hasOwnProperty nicht wirklich als umständlich bezeichnen würde. Für große Datenbestände könnte es übrigens sogar von Vorteil sein, statt Objekte direkt als assoziative Arrays zu (miss-?)brauchen, ein Wrapper-Objekt zu verwenden, das zusätzlich die Objekteigenschaften in einer Liste führt, da for(;;) meines Wissens nach performanter als for...in arbeitet.

4. Aus Bequemlichkeit bevorzugen viele syntaktische Einfachheit und entscheiden statt dessen die Defaultbelegungen zu umgehen (ähnlich den *viel* häufigeren Spezialvariablen in Perl also $_, $a, $b, $0 ,usw...) oder Sonderzubehandeln (Verzicht auf Object.prototype)

Meiner Meinung nach sollte man es im Sinne von Kapselung und dem ganzen guten Programmier-Stil-Gedöns vermeiden, Obect.prototype zu verwenden. Daher kam auch meine Idee von wegen with({Object : MyObject})... bzw. with(Bibliothek), da es so möglich ist, Eigenschaften zu beliebigen (globalen) Objekten hinzuzufügen, ohne den Namensraum zu 'verschmutzen'.

Ich bevorzuge den Terminus Hash!

Das sei dir durchaus gegönnt (wie gesagt, 'Hash' und 'assoziatives Array' können synonym verwendet werden).

(tatsächlich gibts wohl diverse Implementierungen für AA von denen die mit Hashfunktion nur eine Variante darstellt, aber die Implementierung ist ja Transparent)

Du meinst die Implementierung eines assoziativen Arrays mit Hash_tabellen_ (siehe oben). Alternativen wären z.B. binäre Suchbäume und Skip-Listen.

1. Weil er kürzer ist.
2. Weil in JS dann Verwechslungen mit Array() zu nahe liegen.

Ok.

My POV, bitte korrigiert mich.

Bitte schön.

Christoph

[Christoph]

Wer ist denn dieser ominöse Christof?

[KurtZ]

Kurtz gegrüßt

Wer ist denn dieser ominöse Christof?

So ne Type aus Westoffenbach! ;-)

Grüße
 Kurt

[Siechfred]

Ich wollte Dich lediglich auf die bereits existierende hash-Klasse aufmerksam machen, mehr nicht.
Danke, sehr interessant. Aber als Gegenargument taugt es wenig.

Darum ging es mir auch gar nicht; Du hast nach einer hash-Klasse gefragt, ich habe eine genannt, die ich kenne. Das wars auch schon.

Erst wer Object.prototype anfasst braucht dieses Hash() als Workaround.

Nein, warum? Auch ohne prototype ist das Hash-Konstrukt letztlich vom Typ Object mit allen Eigenschaften und Methoden, die ein solches halt mit sich bringt.

Zudem schreibt Peter ausdrücklich und wohlbegründet, warum es in JS keine assoziativen Arrays gibt, sondern dass es sich dabei um einfache Objekte handelt.
Hilf mir, wo genau?

In seinem Posting. Er hat es vielleicht etwas missverständlich formuliert (siehe die von Dir zitierte Passage), meint es aber so, wie ich schrieb (siehe Struppis Antwort). Das hat Peter in mehreren späteren Postings auch klargestellt, u.a. am 31.01.2006. Zur {}-Syntax habe ich auch noch was gefunden: Posting vom 11.04.2006. Und bevor Du mir jetzt wieder unreflektiertes Nachplappern vorwirfst, bitte ich Dich, die oben verlinkten Quellen nachzulesen.

Ansonsten: Falls meine Antworten an Dich in diesem Thread Dir tatsächlich rechthaberisch resp. arrogant erschienen sein sollte, so täte es mir ehrlich Leid, denn so wollte ich sie eigentlich nicht verstanden wissen.

Siechfred

[KurtZ]

Kurtz gegrüßt

Ich wollte Dich lediglich auf die bereits existierende hash-Klasse aufmerksam machen, mehr nicht.
Danke, sehr interessant. Aber als Gegenargument taugt es wenig.

Darum ging es mir auch gar nicht; Du hast nach einer hash-Klasse gefragt, ich habe eine genannt, die ich kenne. Das wars auch schon.

[quote]
»»» du wollest uns eine "Klasse" Hash() bauen, über die gefahrlos mit "for in" iteriert werden kann.

Es gibt bereits eine Klasse hash, das for..in kannst Du damit selber testen.
[/quote]

weist du statt Gegenargumente zu liefern, muss ich den Opponenten auch die Arbeit abnehmen potentielle Gegenargumente (die im Raume stehen) auf ihre Stichhaltigkeit zu prüfen.

Verstehst du was ich meine mit: "...  vergeht mir die Lust, weil ich viel mehr Arbeit reinstecken muss als Billigposter." ???

Erst wer Object.prototype anfasst braucht dieses Hash() als Workaround.

Nein, warum? Auch ohne prototype ist das Hash-Konstrukt letztlich vom Typ Object mit allen Eigenschaften und Methoden, die ein solches halt mit sich bringt.

Wer dieses Hash() nutzen will, braucht Prototype.js. Prototype.js verändert Object.prototype (nomen est omen).

Zudem schreibt Peter ausdrücklich und wohlbegründet, warum es in JS keine assoziativen Arrays gibt, sondern dass es sich dabei um einfache Objekte handelt.
Hilf mir, wo genau?

In seinem Posting. Er hat es vielleicht etwas missverständlich formuliert (siehe die von Dir zitierte Passage), meint es aber so, wie ich schrieb (siehe Struppis Antwort). Das hat Peter in mehreren späteren Postings auch klargestellt, u.a. am 31.01.2006. Zur {}-Syntax habe ich auch noch was gefunden: Posting vom 11.04.2006. Und bevor Du mir jetzt wieder unreflektiertes Nachplappern vorwirfst, bitte ich Dich, die oben verlinkten Quellen nachzulesen.

Nein, ich "werf dir" jetzt vor, dass du von mir erwartest alle Postings von P.Seliger aus dem Archiv zu suchen um zu verstehen, dass er nicht meint, was er gerade formuliert, in den Posts die du verlinkst.

Du so einen Aufwand betreibe ich sonst nur bei Jesus und Mohammed, aber ich verstehe jetzt langsam an wen ihr glaubt! (SCNR)

Komisch, wieso hat ihn Cheatah damals blos nicht angeblafft???

Ansonsten: Falls meine Antworten an Dich in diesem Thread Dir tatsächlich rechthaberisch resp. arrogant erschienen sein sollte, so täte es mir ehrlich Leid, denn so wollte ich sie eigentlich nicht verstanden wissen.

OK, Frieden! :)

Grüße
 Kurt

[molily]

Hallo,

Wer dieses Hash() nutzen will, braucht Prototype.js. Prototype.js verändert Object.prototype (nomen est omen).

Aha. Wo genau wird in Prototype Object.prototype verändert?

Mathias

[KurtZ]

Kurtz gegrüßt

Aha. Wo genau wird in Prototype Object.prototype verändert?

Tatsächlich nirgends, ich hab beim austesten einen Fehler begangen!

Grüße
 Kurt

[KurtZ]

Hi Siechfred

Danke, sehr interessant. Aber als Gegenargument taugt es wenig. Erst wer Object.prototype anfasst braucht dieses Hash() als Workaround.

Ich muss mich korrigieren man kann es auch wohl auch autark nutzen.

Sorry
  Kurt

[Tim Tepaße]

Hallo Siechfred,

Es gibt bereits eine Klasse hash

Der Hash von Prototype tut auch nichts anderes als ein JS-Objekt als Hash zu nutzen, eben weil die interne JS-Implementierung (abseits des in der Aufruforder danach kommenden Prototype-Systems) mit Hashtabellen arbeitet. Prototype nutzt in seiner Implementierung nicht mal die Überprüfung von woher des jeweilige Objekt-Property kommt; aber damit muss man wohl in einem Framework leben, das das Originalsystem mit einer eigenen API so umbastelt, dass angenommen wird, das Originalsystem werde nicht mehr benutzt.

Ich würde es z.B. so oder so ähnlich basteln, würde ich auf der sicheren Seite sein wollen:

~~~javascript function Hash () {
      var store = {};

this.set = function (key, value) {
          store[key] = value;
      }

this.get = function (key) {
          if (store.hasOwnProperty(key)) {
              return store[key];
          } else {
              return undefined;
          }
      }

this.del = function (key) {
          delete store[key];
      }

this.each = function (func) {
          ...
      }
  }

  
(Man verliert natürlich das Zugreifen auf den durch Closure geschützten store bei zusätzlichen Prototype-Methoden, aber ich wollte ja nur das Grundprinzip demonstrieren.)  
  
Letztendlich haben beide Parteien hier im Thread recht. JS-Objekte sind im Sinne von „Watschelt wie eine Ente, quakt wie eine Ente“ Hashes; haben aber noch zusätzliche Semantik durch die prototypische Vererbung; sind praktisch eine Obermenge von Hashes. Wie man das nun genau interpretiert ist nun mal Interpretationssache und ist eine Frage des Standpunktes und der jeweiligen Bedürfnisse.  
  
  
Tim

[Cheatah]

Hi,

du wollest uns eine "Klasse" Hash() bauen, über die gefahrlos mit "for in" iteriert werden kann.

nein, das habe ich nie behauptet.

Googlest du noch um deine "absurde" Behauptung zu untermauern???

_Deine_ absurde Behauptung werde ich ganz sicher nicht untermauern.

Ich schätze eher dein Ego hat einen Knacks bekommen!

Ja, klar, ganz bestimmt. Tut mir leid, Dich enttäuschen zu müssen, aber dazu bist Du für mich *viel* zu unwichtig.

Cheatah

[KurtZ]

Hi

Ja, klar, ganz bestimmt. Tut mir leid, Dich enttäuschen zu müssen, aber dazu bist Du für mich *viel* zu unwichtig.

Ich schätze diese Behauptung werde ich auch nicht wieder aufstellen.

Ich kann nur hoffen dass du dazugelernt hast. (nein ich wär andernfalls nicht entäuscht)

KurtZ

[Cheatah]

Hi,

Ich kann nur hoffen dass du dazugelernt hast.

nein; dass es immer wieder Leute gibt, die eine Sachlage völlig falsch beurteilen und sich darüber hinaus für überaus kompetent wider aller Fachleute halten, wusste ich schon vorher. Auch pi's Law war mir schon bekannt. Nicht mal fachlich konntest Du mir etwas Neues bieten - all Deine Irrtümer habe ich schon von anderen gelesen. Insofern war dieser Thread vergleichsweise langweilig.

(nein ich wär andernfalls nicht entäuscht)

Egomanie, Megalomanie oder einfach nur Desinteresse?

Cheatah

[KurtZ]

  
Object.prototype[1]="b";  
arr=["a"];  
for (i in arr) { alert (arr[i])}  

[Don P]

Hallo,

LOL – schön dass du's einsiehst. Also erst recht keine assoziativen.

Diese Programmiersprache wird mir immer unheimlicher. Fehlt nicht viel, und ein kleines Script backt mir wirklich eine Pizza oder wirft mir gar eine Torte ins Gesicht...

Gruß, Don P

[Struppi]

Object.prototype[1]="b";
arr=["a"];
for (i in arr) { alert (arr[i])}

  
Spaßvogel.  
Jedes Array ist auch ein Objekt, das wurde hier auch mehrmals erwähnt. Nutze die Funktionen die das Array bereitstellt, im gegensatz zum Assoziativen Array gibt es die nämlich für Array.  
  
Struppi.

[KurtZ]

Kurtz gegrüßt

Spaßvogel.

Zugegeben ich plagiere den Object.prototype Witz des hiesigen Cheftrolls.  ...hmmm ... muss ich jetzt Tantiemen an ihn zahlen? ;-)

Jedes Array ist auch ein Objekt, das wurde hier auch mehrmals erwähnt.

muss mir entgangen sein ;-)

Nutze die Funktionen die das Array bereitstellt, im gegensatz zum Assoziativen Array gibt es die nämlich für Array.

Aha! Könntest du mir bitte den Code dahingehend adequat verbessern ?

Insbesondere würde mich interessieren wie man richtig auf Elemente zugreift...
arr.get(idx) ???

Grüße
 Kurt

[Struppi]

Nutze die Funktionen die das Array bereitstellt, im gegensatz zum Assoziativen Array gibt es die nämlich für Array.

Aha! Könntest du mir bitte den Code dahingehend adequat verbessern ?

Object.prototype[1]="b";  
arr=["a"];  
for(var i = 0; i < arr.length;i++) alert(arr[i]);  

Struppi.

[KurtZ]

Kurtz gegrüßt

Nutze die Funktionen die das Array bereitstellt, im gegensatz zum Assoziativen Array gibt es die nämlich für Array.

Aha! Könntest du mir bitte den Code dahingehend adequat verbessern ?

Object.prototype[1]="b";

arr=["a"];
for(var i = 0; i < arr.length;i++) alert(arr[i]);

»  
  
OK, das ändert aber leider nix an der Tatsache das a[1] einen Wert liefert, es gibt keinen echten get() Syntax!  
  
Und wenn eine for-loop eine Funktion ist die das Array zurückliefert, dann ist  
  
~~~javascript
  
Object.prototype[1]="b";  
arr=["a"];  
for (i in arr) if (arr.hasOwnProperty(i))  
  { alert (arr[i])}  

eine for-each loop die "hash" zurückliefert. (übrigens eine genauso lange)

Frieden?!? :)
 Kurt

[KurtZ]

PS:

OK, das ändert aber leider nix an der Tatsache das a[1] einen Wert liefert, es gibt keinen echten get() Syntax!

ja ich hab nicht vergessen das man hasOwnProperty dafür nutzen kann.

Grüße
 Kurt

[Struppi]

OK, das ändert aber leider nix an der Tatsache das a[1] einen Wert liefert, es gibt keinen echten get() Syntax!

Damit hast du eine Schwierigkeit des Indexoperator aufgezeigt, der in JS sowohl für den nummerischen Index bei Arrays als auch für die Eigenschaften der Objekte genutzt werden kann.

Allerdings setzt dein Hinweis auf diese Schwierigkeit nicht die Funktionalität eines Arrays ausser Kraft, wie dein Titel suggeriert, length funktioniert nach wie vor korrekt.

Object.prototype[1]="b";
arr=["a"];
for (i in arr) if (arr.hasOwnProperty(i))
  { alert (arr[i])}

  
Mit all seinen Schwierigkeiten und das es eben nicht in allen Browsern funktioniert. Ich sagte ja bereits, es bleibt dir überlassen mit hasOwnProperty und for in Schleifen zu arbeiten, damit du weiter Hashes nutzen kannst, ohne hast du keine.  
  

> eine for-each loop die "hash" zurückliefert. (übrigens eine genauso lange)  
> Frieden?!? :)  
  
Ich hab nix dagegen dass du Objekte für dich so nennst, erst recht wenn du sie dann immer in Anführungszeichen machst  
  
Struppi.

[KurtZ]

Kurtz gegrüßt

Mit all seinen Schwierigkeiten und das es eben nicht in allen Browsern funktioniert.

das muss mir entgangen sein. wo? meinst du safari <V2? Es ist zumindest ECMA standard.

eine for-each loop die "hash" zurückliefert. (übrigens eine genauso lange)
Frieden?!? :)

Ich hab nix dagegen dass du Objekte für dich so nennst, erst recht wenn du sie dann immer in Anführungszeichen machst

Ich sage nur wer Array sagt muss auch Hash sagen.

Oder sieht jemand ein Argument gegen Object() als Hashersatz das nicht auch gegen Array() vorgebracht werden kann?

Grüße
 Kurt

[Struppi]

Mit all seinen Schwierigkeiten und das es eben nicht in allen Browsern funktioniert.

das muss mir entgangen sein. wo? meinst du safari <V2? Es ist zumindest ECMA standard.

Du kannst die Reihenfolge nicht garantieren mit for in und zur Problematik der alten Browser hab ich hier schon was gesagt.

eine for-each loop die "hash" zurückliefert. (übrigens eine genauso lange)
Frieden?!? :)

Ich hab nix dagegen dass du Objekte für dich so nennst, erst recht wenn du sie dann immer in Anführungszeichen machst

Ich sage nur wer Array sagt muss auch Hash sagen.

Nein, du sagst wer Array sagt muss auch Object sagen, was ja auch stimmt.

Oder sieht jemand ein Argument gegen Object() als Hashersatz das nicht auch gegen Array() vorgebracht werden kann?

Ja du musst in einer Schleife pürfen ob hasOwnProperty() true ergibt.

Struppi.

[KurtZ]

Kurtz gegrüßt

Ich sage nur wer Array sagt muss auch Hash sagen.

Nein, du sagst wer Array sagt muss auch Object sagen, was ja auch stimmt.

Du meinst wohl wer Array() muss auch Object() sagen.

ich kennen kein anderes Wort für Datenstruktur Array das sich vom Object Array() absetzt.

Tabelle?

Oder sieht jemand ein Argument gegen Object() als Hashersatz das nicht auch gegen Array() vorgebracht werden kann?

Ja du musst in einer Schleife pürfen ob hasOwnProperty() true ergibt.

wie gesagt ungefähr gleich lang:

for (var i = 0; i < arr.length;i++) alert(arr[i]);
for (i in arr) if (arr.hasOwnProperty(i)) alert(arr[i]);

außer das letzteres sowohl bei jedem Object() also auch bei Array() wie gewünscht funktioniert. [1]

Grüße
 Kurt

[1] "gewünscht" heißt das kein Spacko anfängt Stringkeys in einer Array-Instanz anzulegen, solche Leute soll der Troll holen.

[molily]

Hallo,

"gewünscht" heißt das kein Spacko anfängt Stringkeys in einer Array-Instanz anzulegen, solche Leute soll der Troll holen.

Wer das bewusst macht, hat JavaScript wirklich verstanden. ;)

Mathias

[Don P]

Kurtz entgegnet :-)

Ich sage nur wer Array sagt muss auch Hash sagen.

Oder sieht jemand ein Argument gegen Object() als Hashersatz das nicht auch gegen Array() vorgebracht werden kann?

Ja: Es ist wie gesagt die length-Eigenschaft, die ein Array auszeichnet und damit verbunden die Möglichkeit, die Array-Elemente mit for(...) und numerischen Indizes zu durchlaufen, wie sich das für Array gehört. for-in ist dafür *nicht* gedacht und auch *nicht* wirklich geeignet, aus dem gleichen Grund, warum ein Objekt eben nicht einfach als Hash oder "assoziatives Array" bezeichnet werden sollte, d.h. wegen möglicher zusätzlicher Eigenschaften im Prototyp.

Die length-Eigenschaft eines Array lässt sich nämlich nicht austricksen durch etwas wie Object.prototype[99] = "bla"; vor dem Erzeugen neuer Arrays. Das hundertste Element dann allerdings schon: Wenn man anschließend z.B. var array = new Array(100); notiert, wäre array[99] eigentlich undefined, täuscht aber ganz frech "bla" vom Prototyp vor.

Analog lässt sich die Länge eines Hashs z.B. in Perl einfach ermitteln durch Zählen der Elemente: my $size = scalar(keys %hash);
Ein for..in über die Eigenschaften eines JavaScript-Objekts ist da aber nicht zuverlässig.

Zusammenfassend kann man also sagen:

Wenn es in JavaScript keine prototypische Vererbung gäbe und nicht alles außer Primitives Objekte wären, wäre ein JS-Array ein herkömmlicher Array und ein mit new Object() erzeugtes JS-Objekt ein herkömmlicher Hash.

Oder anders formuliert: Da JavaScript prototypische Vererbung kennt mit allem, was kein Primitive ist, gibt es in JS kein herkömmliches Array und auch keinen herkömmlichen Hash.

Das war jetzt aber eine schwere Geburt bis hierhin, oder bist du noch immer nicht zufrieden?

Gruß, Don P

[KurtZ]

Kurtz erwiedert ;)

Das hundertste Element dann allerdings schon: Wenn man anschließend z.B. var array = new Array(100); notiert, wäre array[99] eigentlich undefined, täuscht aber ganz frech "bla" vom Prototyp vor.

Danke, schönes Beispiel!

Das war jetzt aber eine schwere Geburt bis hierhin, oder bist du noch immer nicht zufrieden?

doch ich habs nur anders formuliert https://forum.selfhtml.org/?t=169127&m=1105115

Leider ist JS eine Sprache mit sehr eng beieinanderliegenden und missverständlichen Termini.

Grüße
 Kurt

[molily]

Hallo,

die Möglichkeit, die Array-Elemente mit for(...) und numerischen Indizes zu durchlaufen, wie sich das für Array gehört. for-in ist dafür *nicht* gedacht und auch *nicht* wirklich geeignet

for-in ist dafür im Prinzip genauso geeignet und nicht geeignet wie for, denn ...

d.h. wegen möglicher zusätzlicher Eigenschaften im Prototyp.

...die hauen auch bei for rein.

Ist halt die Frage, wie man mit »Lücken« umgehen will. Prinzipiell ist es nicht unbedingt dumm, Arrays mit for-in zu durchlaufen.

Die length-Eigenschaft eines Array lässt sich nämlich nicht austricksen durch etwas wie Object.prototype[99] = "bla"; vor dem Erzeugen neuer Arrays.

Ja, dann bekommt man, wenn man mit for von 0 bis length läuft, viele undefined. Muss ja nichtmal durch Vererbung gesetzt sein.

Mathias

[molily]

Hallo,

Damit hast du eine Schwierigkeit des Indexoperator aufgezeigt, der in JS sowohl für den nummerischen Index bei Arrays als auch für die Eigenschaften der Objekte genutzt werden kann.

Naja, es ist halt derselbe Operator (Property Accessor). arr[1] ist genau dasselbe wie arr["1"] und arr[1] wird intern sowieso in arr["1"] umgewandelt, weil Eigenschaftsnamen immer Strings sind.

Mathias

[molily]

Hallo,

Klar, Arrays sind nichts als Objects mit Eigenschaften namens "0", "1", "2" usw. und einem speziellen Verhalten bei [[Put]], sprich, beim Anlegen von Eigenschaften.

»Array objects give special treatment to a certain class of property names. A property name P (in the form of a string value) is an array index if and only if ToString(ToUint32(P)) is equal to P and ToUint32(P) is not equal to 2^32 - 1.« usw. http://bclary.com/log/2004/11/07/#a-15.4

Mathias

[Harlequin]

Yerf!

Ich würd ja eher sagen JavaScript hat ganz einfach kein for each...

Gruß,

Harlequin

[KurtZ]

Hi Ric

Kurtz beantwortet:

ok ich wollte dir ne kurze Antwort geben, aber ich muss etwas weiter ausholen.

ist aber gleichzeitig JS Form eines assoziativen Arrays!

Es ist eine "Form" assoziative Arrays zu realisieren, zumindest wirst du es sehr häufig in dieser Art sehen.

Das funtioniert auch sehr gut solange man auf bekannte hashkeys zugreift, leider herscht das Missverständnis (auch bei hiesigen "Kennern") das eine
for-in Schleife über die eigenen Schlüssel eines Hashes iterieren solle.

das ist leider falsch es iteriert über die eigenen und die geerbten Schlüssel, der in-Operator durchsucht den ganzen prototype-chain bis zum Top-Objekt. Es gibt  leider kein "for-own" Befehl in JS.

Wenn du dich nicht mit OOP befassen willst kann es dir reichen einfach folgendes zu beherzen:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Object.prototype ist Tabu
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Es ist IMHO leider auch nicht möglich einen Konstruktor (das Analoge zu Klassen in JS) zu generieren der nicht von Object() erbt, deswegen würde jedes for-in also auf die Schnauze fallen.

In den meisten Fällen begnügt man sich also damit {key:value} für Hashes zu nutzen und genau zu kontrollieren was Object vererbt. (die builin Attribute von Object werden von for-in nämlich GENAU FÜR DIESEN ZWECK ignoriert). Und dadurch das man das Top-Object der Vererbungskette nimmt, ist man auch sicher das kein Object in der Vererbungskette was reinschmuggelt.

Solltest du aber unbedingt Object.prototype verändern wollen, wird ein nacktes for-in für dich Tabu, du musst also sowas schreiben

for (variable in object) if (object.hasOwnProperty(variable)) {
        statements;
    }

Wenn dir das zu umständlich ist bleibt dir nur noch der Weg eine Wrapper-Funktionen zu bauen, die dies kapseln

also sowas wie ownValue(key,Object) oder sogar ein Objekt Hash konstruieren das eine Methode definiert Hash.ownValue(key) definiert hat und implizit auf hasOwnProperty prüft.

eine "Klasse" Hash die das for-in "problem" nicht hat, kann es leider nicht geben. Was aber in kontrollierten Fällen totaler Overhead ist.

Das Problem ist also nicht Object als Hash zu benutzen, sondern falsch auf die Werte zuzugreifen, udn z.B. for-in mit einem foreach wie z.B. in Perl zu verwechseln.

Das ist ein Designfehler in JS. Aber in den meisten Fällen kannst du es ziemlich genau kontrollieren, deswegen verzichten viele Progger aus Bequemlichkeit da auf das Sicherheitsnetz  mit hasOwnProperty.

Hoffe du kannst nun deren Code besser verstehen.

Tschau
 Kurt

[Struppi]

var x = new Object();

ist aber gleichzeitig JS Form eines assoziativen Arrays!

x={a:1};
x.a == 1;

Vielleicht sollte man im Rahmen der Diskussion etwas weiter ausholen.

Einige die hier mit JS zu tun haben, haben damit vor langer Zeit angefangen, ich persönlich seit Netscape 3 (da ist mir auch das erste mal Cheatah begegnet und ich weiß das auch Cybaer mindestens so lange damit arbeitet). Der konnte weder die literale Schreibweise und erst recht gab es damals nicht hasOwnProperty und ich bin noch nicht mal sicher, dass es prototype zu der Zeit schon gab. Oder, um die Schwierigkeit mit deiner Lösung aufzuzeigen, selbst for in gibt es erst seit dem IE 5, wenn ich MSDN richtig deute (MDC sagt was anderes). Das heißt, es ist noch gar nicht solange möglich ein Objekt als assoziatives Array zu nutzen. Als eine einfache hash-table sehr wohl, aber mit der Schwierigkeit, dass es nicht möglich war über die Attribute zu iterieren.

Da die Browser offensichtlich grosse Sprünge gemacht haben, um solche programmiertechnische Probleme zu überwinden, scheint es so, als ob die Verwendung eines Objektes als AA nicht mehr viel im Wege steht.

Die gleiche Entwicklung kannst du auch verfolgen wenn es um die Verwendung von innerHTML geht, dass am Anfang sehr verpöhnt war, da es von M$ kam und auch nur von wenigen Browsern überhaupt umgesetzt wurde (wobei innerHTML durchaus Probleme machen kann, aber das ist ein anderes Kapitel) oder eben auch, wie du schon angemerkt hast beim with() das auf einmal nicht mehr verwendet werden sollte (was sich wieder geändert hat)

D.h. du kannst mit deinen Kenntnissen über die momentanen Möglichkeiten von JS durchaus zu dieser Aussage kommen, wirst aber keine Zustimmung von Leuten bekommen, die noch gewohnt sind abwärtskompatibel zu denken und/oder zu programmieren. Das spiegelt also lediglich den aktuellen Erfahrungshorizont wieder und wird sich ändern. Ich bin mir zwar nicht sicher, ob du mit der Aussage ein Objekt ist ein assoziatives Array richtig liegst, da ich keine offzielle Erklärung kenne und du wikiedia nicht akzeptierst. Das dürfte aber keine Rolle spielen, denn für die einen, die noch die Erfahrung der unbedingten Abwärtskompatiblität und die Langsamkeit der Entwicklung haben, ist es in der momentanen Phase kein AA und für dich ist es eines, da für dich hasOwnProperty selbstverständlich ist, während ich mir das noch nicht mal angeschaut hatte.

Genau genommen hatte ich mir die Seite auf dem MDC noch gar nicht angeschaut, denn alle 2-3 Jahre gab es bisher eine grosse Entwicklung, die dazu führt das man sich ellenlange, meist englisch sprachige Seiten, durchlesen müßte, wovon dann aber nur ein Bruchteil der neuen Dinge praktisch nutzbar ist, weil es nur ein geringer Teil der Browser umsetzt. D.h. man ist möglichst behutsam bei neuen Features und verfolgt Diskussionen, wie z.b. hier.

Ich halte das für eine normale Sache, dass man sich über techn. Entwicklungen und deren praktische Bedeutung mit anderen auseinandersetzt und davon lernt. Gerade diese Diskussion hier, habe ich schon Dutzendfach verfolgt und mitgemacht. Und jedesmal dabei etwas neues gelernt. So wie auch diesmal. Ich finde es zwar seltsam, dass es dabei oft sehr schnell polemischen wird, aber das gehört wohl zu technischen Diskussionen dazu, gerade wenn es um Dinge geht, die nicht wirklich geklärt sind (wie gesagt die offzielle Definition für AAs fehlt noch). Aber alles in allem gab es mal wieder eine fruchtbare Diskussion, die zwar von ein paar Entgleisungen begleitet war, aber gerade an sowas sieht man wo es noch Erklärungsbedarf gibt, was gerade für selfhtml eine nützlich Sache für die zukünftige Dokumentation ist.

So! wir haben alle was gelernt :-)

Struppi.

[KurtZ]

Hi

Oder, um die Schwierigkeit mit deiner Lösung aufzuzeigen, selbst for in gibt es erst seit dem IE 5, wenn ich MSDN richtig deute (MDC sagt was anderes). Das heißt, es ist noch gar nicht solange möglich ein Objekt als assoziatives Array zu nutzen. Als eine einfache hash-table sehr wohl, aber mit der Schwierigkeit, dass es nicht möglich war über die Attribute zu iterieren.

kann es ein dass du for-in mit dem in-Operator verwechselst?
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Statements:for...in
da steht JS 1.0

Die gleiche Entwicklung kannst du auch verfolgen wenn es um die Verwendung von innerHTML geht, dass am Anfang sehr verpöhnt war, da es von M$ kam und auch nur von wenigen Browsern überhaupt umgesetzt wurde (wobei innerHTML durchaus Probleme machen kann, aber das ist ein anderes Kapitel) oder eben auch, wie du schon angemerkt hast beim with() das auf einmal nicht mehr verwendet werden sollte (was sich wieder geändert hat)

Ich kennen kein deprecated bei with, Grandmaster Crockford et.al. polemisieren dagegen, es sei überflüssig, verwirrend, verführe zu Fehlern!

Das dürfte aber keine Rolle spielen, denn für die einen, die noch die Erfahrung der unbedingten Abwärtskompatiblität und die Langsamkeit der Entwicklung haben, ist es in der momentanen Phase kein AA und für dich ist es eines, da für dich hasOwnProperty selbstverständlich ist, während ich mir das noch nicht mal angeschaut hatte.

Du Struppi, ich habe auch mit NN4 angefangen zu scripten, und wenn es IMHO eine neue Entwicklung gab, war es diejenige, das manche Leute anfiengen  Object.prototype für sich zu entdecken, so dass der Bedarf an hasOwnProperty() aufkam.

Object als Hash zu nutzen ist IMHO volle Absicht im Design, for-in skipt ja auch absichtlich die Defaultmethoden aus Object.prototype um das zu ermöglichen. Hash() wurde so bewusst eingespart.

Trotzdem hat JS da IMHO da leider Designfehler.

Man kann sich IMHO jetzt auf zwei Standpunkte stellen:

1. Es "gibt" in JS nur Primitiva, Objecte und Funktionen weil es keine anderen *Datentypen* gibt.

2. Es "gibt" auch Arrays und Hashes, deren Verhalten in den Objekten Array() und Object() simuliert werden, allerdings mit kleinen Abstrichen bedingt durch das Objektsystem.

Sich aber ne Mischform aus 1 und 2 zu wählen, ist entweder Inkonsequent oder Scheinheilig.

Diejenigen die also erst polemisieren und dann auch noch die Antwort schuldig bleiben, wie sie es denn besser machen, die sind IMHO letztendlich nur Trolle im Schutze der Mehrheitsmeinung.

Aber ich denke wir beide sind uns soweit einig, dass es nur noch eine Frage der Terminologie ist.

Tschüss
  Kurt

[molily]

Hallo,

Trotzdem hat JS da IMHO da leider Designfehler.

Naja, was ist das für eine Erkenntnis. ECMAScript Edition 3 ist da halt ziemlich radikal und »billig«, das gibts meines Wissens so in keiner anderen (verbreiteten) Programmiersprache. Diese Konsequenz macht ES3 ziemlich logisch und für mich »einfach«. Edition 4 räumt das alles beiseite, was aus meiner Sicht nicht nur Vorteile mit sich bringt:
http://www.ecmascript.org/es4/spec/overview.pdf

Mathias

[KurtZ]

Kurtz gegrüßt

Naja, was ist das für eine Erkenntnis. ECMAScript Edition 3 ist da halt ziemlich radikal und »billig«, das gibts meines Wissens so in keiner anderen (verbreiteten) Programmiersprache.

Ich sage *syntaktisch* fehlt einiges, der semantischer Minimalismus ist OK!

Z.B fehlt ein Vererbungsbfreies get auf ein Objekt udn ein vererbungsfreies for-each, dann gäbs diesen Thread gar nicht.

also Beispielsweise

a<key> := a.hasOwnProperty[key] ? a[key]: undefined;

oder

for ( x owned obj)

Statt Spracherweiterungen sollte es vielleicht einen Macroprozessor geben...

Grüße
  Kurt

[Christoph]

Moin.

Statt Spracherweiterungen sollte es vielleicht einen Macroprozessor geben...

Es würde schon genügen, wenn sich JavaScript zur prototypischen Programmierung 'bekennen' und von der doch etwas gewöhnungsbedürftigen Vererbungshierarchie Abstand nehmen würde (wozu brauche ich constructor.prototype, wenn es __proto__ gibt?).

Außerdem sollte auf 'magische' Objekteigenschaften verzichtet werden. Wieso kann ich z.B. hasOwnProperty nicht durch eine eigene Funktion ersetzen? Mozilla hat mit __iterator__ in diesem Sinne einen Schritt in die richtige Richtung gemacht. Ich würde mir halt vor allem wünschen, auch __proto__ diekt bearbeiten zu können...

Christoph

[KurtZ]

Kurtz gegrüßt

Es würde schon genügen, wenn sich JavaScript zur prototypischen Programmierung 'bekennen' und von der doch etwas gewöhnungsbedürftigen Vererbungshierarchie Abstand nehmen würde (wozu brauche ich constructor.prototype, wenn es __proto__ gibt?).

Wahrscheinlich um irgendeine inner Konsistenz zu  erzwingen ... z.B. dass alle Objekte ohne Ausnahme letztendlich von Object.prototype erben ...

Ciao
 Kurt

[KurtZ]

Kurtz gegrüßt

Wahrscheinlich um irgendeine inner Konsistenz zu  erzwingen ... z.B. dass alle Objekte ohne Ausnahme letztendlich von Object.prototype erben ...

Also mir würde helfen dieses magische Flag setzen zu könnne, das Properties für for-in ausblendet.

Grüße
 Kurt

[Christoph]

Moin.

Mit Hilfe von Mozilla's JavaScript 1.7 Iterators lässt sich for...in gezielt steuern. Damit lässt sich z.B. folgendes realisieren:

<pre><script type="application/javascript;version=1.7">~~~javascript

Object.prototype.answer = 42;

function assoc(obj) {
 obj = obj || {};
 function Assoc() {}
 Assoc.prototype.iterator = function() {
  let it = Iterator(obj);
  return {
   next : function() {
    while(true) {
     let [key, value] = it.next();
     if(obj.hasOwnProperty(key))
      return [key, value];
    }
   }
  };
 };
 return new Assoc;
}

let a = assoc({ spam : 'eggs'});

for(let [key, value] in a) {
 document.writeln(key + ' : ' + value);
}

  
Vielleicht findet jemand eine noch einfachere Implementierung; diese hier scheint aber bereits zu funktionieren.  
  
Christoph

[Christoph]

function assoc(obj) {
obj = obj || {};
function Assoc() {}
Assoc.prototype.iterator = ...

  
Das ist natürlich Murks, jedesmal den Iterator im Prototyp neu zu setzen. So sollte es besser funktionieren:  
  
~~~javascript
  
function Assoc(obj) {  
 if(!(this instanceof Assoc))  
  return new Assoc(obj);  
  
 obj = obj || {};  
  
 this.__iterator__ = function() {  
  let it = Iterator(obj);  
  
  return {  
   next : function() {  
    while(true) {  
     let [key, value] = it.next();  
     if(obj.hasOwnProperty(key))  
      return [key, value];  
    }  
   }  
  };  
 };  
}  
  
let a = Assoc({ spam : 'eggs'});  

[Tim Tepaße]

Hallo Christoph,

Wenn wir schon im entfernten Lande von Mozillas JS 1.7 sind, dann können wir gleich alle von Python geborgten Goodies nehmen und mit etwas JS-Eigenheiten vermischen. Mal so rein intuitiv dahin gewurschtelt, ungetestet:

~~~javascript function betterHash (obj) {
      var obj = obj || {};

obj.iterator = function (keysonly) {
          var keysOnly = keysOnly || false;
          for (key in this) {
              if (this.hasOwnProperty(key) {
                  yield (keysOnly) ? key
                                   : [key, this[key]];
              }
          }

};

return obj;
  }

  
Schließlich ist ein Generator auch ein Iterator. Mit Mozillas JS 1.8, dass sich auch die Generator Expressions von Python geklaut hat kann man den Code auch noch verkürzen:  
  
  ~~~javascript
function betterHash (obj) {  
       var obj = obj || {};  
  
       obj.__iterator__ = ([key, this[key]] for (key in this)  
                                            if (this.hasOwnProperty(key)));  
  
       return obj;  
  }

Wie gesagt ungetestet, da mein Spidermonkey es nicht kann. Das ist hier nur meine pythonische Erfahrung, die da spricht. Natürlich ist es in der Realität nicht nutzbar, auch wäre es nicht toll, weil andere Elemente einer syntaktischen Harmonisierung eines Hashs, Dict, Maps, Assoziativen Arrays in der Sprache fehlen, inbesondere der Zugriff und das setzen mit den []-Operatoren. Erst in JS 2.0 / ES4 werden die auf entsprechende Methoden abgebildet und damit überladbar. Aber wozu? In ECMAScript 4 bzw. JavaScript 2.0 wird's dann eh (in 2015 oder so) die Klasse Map geben, die genau das leistet, was man will.

Tim

[Christoph]

Moin.

Mal so rein intuitiv dahin gewurschtelt, ungetestet:

Hättest du mal tun sollen ;)

[code lang=javascript]function betterHash (obj) {
      var obj = obj || {};

obj.__iterator__ = function (keysonly) {
          var keysOnly = keysOnly || false;
          for (key in this) {

too much recursion:  ^^^^---- hier wird __iterator__ erneut aufgerufen

Christoph

[Tim Tepaße]

Hallo,

too much recursion:  ^^^^---- hier wird __iterator__ erneut aufgerufen

Arghs. Klar. Man sollte sich um zwei Uhr nachts halt nicht klüger vorkommen, als es die Uhrzeit einem erlaubt. ;)

Tim

[Struppi]

Mit Hilfe von Mozilla's JavaScript 1.7 Iterators lässt sich for...in gezielt steuern. Damit lässt sich z.B. folgendes realisieren:

Das mag für einen geschlossenen Benutzerkreis mit definierten Browsern praktikabel sein, aber ich bleib lieber vorerst noch bei einem simplen Objekt das ich als einfach als Hashtable mißbrauche.

Das funktioniert in fast allen Browsern die momentan in der Wildbahn vorkommen und ist halbwegs durchschaubar. Ob dies nun von manchen so der so genannt wird ist egal, solange klar ist, es hat nichts mit einem Array (die Namensähnlichkeit könnte zu Verwechslungen führen) zu tun und ausser einer for in Schleife gibt es auch keine Funktionalität und selbst dann muss ich aufpassen, dass man mir keine fremden Skripte dazwischen pfuschen.

Im Zweifelsfall würde ich mir dann lieber eine eigene Klasse bauen, mit der ich dann auch die Anzahl der keys oder eine sortierte Ausgabe verwirklichen kann. Alles Dinge die ich vorrausetzten würde, bevor ich sowas einen Hash oder AA bezeichnen würde, die es aber in JS definitiv nicht gibt. Aber es gibt, wie wir hier festgestellt haben, unterschiedliche Auffassungen der Definition. Insofern ist eigentlich alles gesagt, jeder macht das Gleiche nur jeder nennt es anders.

Struppi.