Namespace?

[bleicher]

Grüße,
Hier, wird bei "Adding behavior to the buttons" folgendes Verwendet:

  
// define a namespace to hold our widget specific functions,  
// avoid polluting the global namespace  
var helloWorld = helloWorld || {};  

ich habe versucht nach "Namespace" zu googeln, doch waren die ergebnisse anders - was ist das für "|| {}"?

zudem mein Versuch es zu verwenden scheiterte ;/

  
var tooltip=tooltip||{};  
  
tooltip.makebox=function(){  
...  
}  

es heißt (logischerweise) in der Fehlermeldung "UNdefined variable 'Tooltip'"
MFG
bleicher

[Der Martin]

Hallo,

// define a namespace to hold our widget specific functions,

// avoid polluting the global namespace
var helloWorld = helloWorld || {};

  
das ist spaßig: Da wird eine lokale Variable "helloWorld" angelegt, und ihr wird entweder der Wert von "helloWorld" zugewiesen, falls das bereits existiert, ansonsten ein "leeres" Objekt.  
  

> ich habe versucht nach "Namespace" zu googeln, doch waren die ergebnisse anders - was ist das für "|| {}"?  
  
Das sind drei Tricks in einem. Einerseits ist || der logische ODER-Operator. Andererseits ist er so definiert, dass a||b a zurückgibt, wenn a existiert und nicht Null ist, andernfalls b. Dazu kommt noch, dass der Ausdruck {} das gleiche ist wie new Object().  
  

> ~~~javascript

var tooltip=tooltip||{};  

>   
> tooltip.makebox=function(){  
> ...  
> }

Soweit korrekt.

es heißt (logischerweise) in der Fehlermeldung "UNdefined variable 'Tooltip'"

Ja, weil "tooltip" nicht dasselbe ist wie "Tooltip".

So long,
 Martin

[unknown]

das ist spaßig: Da wird eine lokale Variable "helloWorld" angelegt, und ihr wird entweder der Wert von "helloWorld" zugewiesen, falls das bereits existiert, ansonsten ein "leeres" Objekt.

Wobei das nicht nur spaßig ist. Zur initialisierung optionaler Parameter in Funktionen ist das durchaus sinnvoll.

[Cybaer]

Hi,

Wobei das nicht nur spaßig ist. Zur initialisierung optionaler Parameter in Funktionen ist das durchaus sinnvoll.

Ich nenne das: Überflüssige Fehlerquelle.

Schließlich kann ein Parameter auch einen unwahren Wert beinhalten ...

Gruß, Cybaer

[Timo "God's Boss" Reitz]

Wobei das nicht nur spaßig ist. Zur initialisierung optionaler Parameter in Funktionen ist das durchaus sinnvoll.

Ich nenne das: Überflüssige Fehlerquelle.

Schließlich kann ein Parameter auch einen unwahren Wert beinhalten ...

Kommt darauf an. Ich benutze das in der Form nur, wenn ein Objekt erwartet wird und sonst ein Standard-Objekt benutzt wird (1) oder wenn der Vorgabewert ein „falsy value“ ist derart, dass er der einzig Mögliche sein soll (2).

Beispiel für (1):

function doSomething(obj, optionalObj){
  optionalObj=optionalObj||{ /* … */ }; // Oder auch new …(…);
  /* … */}

Beispiel für (2):

function doSomethingWithN(n){
  n=n||0;
  /* … */}

[unknown]

Ich nenne das: Überflüssige Fehlerquelle.

Schließlich kann ein Parameter auch einen unwahren Wert beinhalten ...

Dann spricht aber auch nichts gegen:
param = param || false;
bei boolschen Parametern bzw.
param = param || 0;
was bei optionalen Parametern die 99,9% Initialisierung sein wird. Aber wenn es sich nicht um Objekte handelt, auf die man mit param.prop zugreifen will, kann man in diesem Fall meist auch ganz auf eine Initialisierung verzichten, da ein
if (param)
in egal ob 0, false, null oder halt undefined das gleiche Ergebnis liefert.
Aber ich weiss was du sagen willst, stimme dir allerdings nicht zu.

[Cybaer]

Hi,

Dann spricht aber auch nichts gegen:

Ja, wenn man genau weiß, was für Parameter kommen (können).

Aber wenn es sich nicht um Objekte handelt, (...) Aber ich weiss was du sagen willst, stimme dir allerdings nicht zu.

Ich habe öfters den Fall, daß ich die optionalen Parameter mit einem (wahren) Defaultwert vorbelege. Und wenn der Parameter wirklich nicht übergeben wurde, dann kann man das am einfachsten mit typeof() ermitteln. Wenn der Parameter undefined ist, *dann* ist ist klar, daß er nicht übergeben wurde - auch nicht mit false null oder sonstwas als Wert ...

... und da kann man diese Syntax dann eigentlich auch einheitlich immer und überall verwenden, sofern nicht explizit was dagegen spricht.

Gruß, Cybaer

[unknown]

Ich habe öfters den Fall, daß ich die optionalen Parameter mit einem (wahren) Defaultwert vorbelege.

Mag sein.

Und wenn der Parameter wirklich nicht übergeben wurde, dann kann man das am einfachsten mit typeof() ermitteln.

Wieso mit typeof()? Wieso ist das einfacher als
if (param === undefined)

Wenn der Parameter undefined ist, *dann* ist ist klar, daß er nicht übergeben wurde - auch nicht mit false null oder sonstwas als Wert ...

Ob der Parameter nicht übergeben wurde ist aber nur interessant, WENN er im Defaultfall ungleich 0, false, null vorbelegt sein soll. Davon gehe ich aber erst mal aus. Sonst bleibt natürlich nichts anderes übrig, als zu prüfen, ob der Parameter übergeben wurde.

... und da kann man diese Syntax dann eigentlich auch einheitlich immer und überall verwenden, sofern nicht explizit was dagegen spricht.

kann man, muß man aber nicht.

Man kann vieles machen, um Fehler zu vermeiden. Viele schreiben auch
if (KONSTANTE == variable)
um versehentliche Zuweisungen zu vermeiden, was meiner Meinung nach die Lesbarkeit zerstört(wobei ich auch zugebe, daß in diesem Fall deine Variante deutlicher lesbar ist) - es hat halt alles Vor- und Nachteile. Fehler werden immer auftreten. Und wenn man sich bewusst ist, was man macht, vermeidet man meiner Meinung nach mehr Fehler als mit starren Regeln wie "diesen Ausdruck sollte man vermeiden, weil er in offensichtlichen Konstellationen zu Fehlern führt".

[Cybaer]

Hi,

Wieso mit typeof()? Wieso ist das einfacher als
if (param === undefined)

Wieso "einfacher"?

Aber *prinzipiell* verwende ich die abwärtskompatiblere Variante, wenn für ein Problem mehrere Lösungsmöglichkeiten existieren.

Und wenn man sich bewusst ist, was man macht, vermeidet man meiner Meinung nach mehr Fehler als mit starren Regeln wie "diesen Ausdruck sollte man vermeiden, weil er in offensichtlichen Konstellationen zu Fehlern führt".

Jo. Und wenn ich typeof() verwende, bin ich mir dessen sehr bewußt.

Gruß, Cybaer

[unknown]

Wieso "einfacher"?

Du hast "einfacher" ins Spiel gebracht!

Aber *prinzipiell* verwende ich die abwärtskompatiblere Variante, wenn für ein Problem mehrere Lösungsmöglichkeiten existieren.

Was bedeutet abwärtskompatiblere Variante? Browserbugs? Dann wäre ein Hinweis angebracht.

[molily]

Was bedeutet abwärtskompatiblere Variante? Browserbugs?

Vorsintflutliche Nicht-ECMAScript-konforme Browser unterstützten === undefined nicht. === und undefined wurden »erst« mit Netscape JavaScript 1.3 engeführt und nicht alle JavaScript-fähigen Browser unterstützen beides. Das betrifft m.W. etwa Netscape 4 und IE 5, aber m.W. keinen Browser, für den man heute noch programmiert. Aber das ändert natürlich Cybaers Meinung nicht. Der Grund, warum ich es nicht angemerkt hatte, des lieben Friedens wegen. ;)

Mathias

[Cybaer]

Hi,

Was bedeutet abwärtskompatiblere Variante?

Zu molilys insgesamt zutreffender Anmerkung (:)), sein noch hinzugefügt, daß auch "===" erst "später" hinzugekommen ist (JS 1.2).

Und auch wenn ich nicht "für" alte Browser programmiere, so code ich doch so, daß auch Scripts mit aktuellsten Features auf älteren JS-Implementationen möglichst keine Fehler produzieren.

Und wenn ein Script das nicht "aktuellste" Features nutzt dann auch noch auf älteren JS-Versionen läuft, bin aber auch nicht "verzweifelt" ... ;->

Gruß, Cybaer

[molily]

var helloWorld = helloWorld || {};

das ist spaßig:

Was meint ihr damit, dass das »spaßig« sei? Falls das negativ gemeint war: Ich halte diese Vorgehensweise für okay - was ist daran auszusetzen?

Mathias

[Der Martin]

Hallo,

var helloWorld = helloWorld || {};
das ist spaßig:
Was meint ihr damit, dass das »spaßig« sei?

ich kann nur für mich sprechen: Ich meinte damit, dass es mich immer wieder amüsiert, wie man in Sprachen wie Javascript oder PHP Krücken benutzt (was hat x für einen Typ, existiert x überhaupt?), die man in einer Sprache mit festen Regeln gar nicht bräuchte.
Und dann amüsiert mich, wie manche Leute diese laxe Flexibilität der Sprache loben, und dann rudern, um die Nachteile dieser Flexibilität in den Griff zu kriegen.

Falls das negativ gemeint war: Ich halte diese Vorgehensweise für okay - was ist daran auszusetzen?

Unter den gegebenen Voraussetzungen der Sprache: Ja, finde ich auch okay.

Schönen Abend noch,
 Martin

[Cybaer]

Hi,

ich kann nur für mich sprechen:

Gut, denn ...

Ich meinte damit, dass es mich immer wieder amüsiert, wie man in Sprachen wie Javascript oder PHP Krücken benutzt (was hat x für einen Typ, existiert x überhaupt?), die man in einer Sprache mit festen Regeln gar nicht bräuchte.

... "brauchen" tut man das in JS auch nicht. Daß das eine "Krücke" sein soll, sehe ich auch nicht. Und ich finde es gerade eine der Stärken von JS, daß man ein Problem i.d.R. auf mehreren Wegen lösen kann. :)

Gruß, Cybaer

[Struppi]

Hier, wird bei "Adding behavior to the buttons" folgendes Verwendet:

// define a namespace to hold our widget specific functions,
// avoid polluting the global namespace
var helloWorld = helloWorld || {};

>   
> ich habe versucht nach "Namespace" zu googeln, doch waren die ergebnisse anders - was ist das für "|| {}"?  
  
Das hat nichts mit dem Namespace zu tun. Namespace ist nur der Begriff für einen begrenzten Gültigkeitsbereich von Funktionen und Variabeln. Weil es in JS keinen Befehl dafür gibt, wird oft einfach ein Objekt dafür verwendet.  
  
Den Fehler hat die Martin schon genannt.  
  
Struppi.