VBScript - inkonzequente Parameterübergabe/Auswertung von WSH/VBScript

[Power-Kiddy 10]

Hallo!

 

Ich versuche meine SUBs so aufzubauen, daß diese robust und wenig Fehleranfällig sind - das sollte jeder so machen ;-)

 

Oft währe es wünschenswert, daß Argumente auch "leer" bleiben und diese dann in der SUB-Prozedur mit einem Standard-Wert "gefüllt" werden.

 

z.B:

Call Testsub(A,,C)

Sub TestSub(A,B,C)
 if Typename(B) = "Error" then B = "Hugo" ' wenn leer übernommen dann Standardwert!
 ...
End Sub

 

Das geht so auch!

Das Argument "B" wurde hier bewußt weg gelassen und in der SUB prüfe ich das und weise diese einen Standardwert zu.

 

Leider kann das letzte Argument (C in dem Fall) nicht leer bleiben, da kriege ich einen Error:

Call Testsub(A,B,) ' geht nicht
Call Testsub(,,)   ' geht auch nicht
Testsub A, B,      ' geht auch nicht
Testsub ,,          ' geht auch nicht!

Sub TestSub(A,B,C)
 if Typename(C) = "Error" then C = "Hugo"
 ...
End Sub

 

Das ist doch recht inkonzequent.

Die Syntax sollte zumindest bei der Version mit "Call x()" keine Probleme haben weil die Klammern die Argumente kapseln.

 

So wie es aussieht können alle Argumente "leer" bleiben nur das letzte nicht.

Das ist doch Murks?

Hat sich schon mal jemand darüber Gedanken gemacht?

 

tks!

Kiddy

bearbeitet 5. August 2009 von Power-Kiddy
mehr Informationen

[NilsK 2.785]

Moin,

 

So wie es aussieht können alle Argumente "leer" bleiben nur das letzte nicht.

Das ist doch Murks?

 

naja, ob das Murks ist ... dann ist ziemlich viel an VBS Murks. Es ist halt eine Skriptsprache, die bewusst einfacher gehalten ist als "echte" Programmiersprachen. Es gibt ja auch keine ordentliche Fehlerbehandlung. Und inkonsequent ist auch der unterschiedliche Aufruf derselben Funktion als Prozedur (Aufruf ohne Klammern) und als Funktion (Aufruf mit Klammern).

 

Hat sich schon mal jemand darüber Gedanken gemacht?

 

Mir war der Umstand, auf den du hinweist, bis eben gar nicht bekannt. Ich finde ihn aber auch nicht besonders nützlich, denn letztlich muss ich eine Funktion oder Prozedur trotzdem immer ordentlich aufrufen. Automatisierte Fehlerbehandlungen können nur grobe Fehler abfangen, mehr nicht.

 

In sofern würde ich an der Stelle nicht weiterforschen. Immerhin wird VBS ja auch nicht weiterentwickelt.

 

Gruß, Nils

[zahni 521]

Och, was meinst Du wie empfinslich 'ne richtige Programmiersprache ist. Wenn Du da auch ur ausversehen den falschen Datentyp (dafür intressiert sich eine Scriptsprache nur in spziellen Fällen) übergibst, wird Dir das um die Ohren gehauen. Also benutze Variablen immer schön initialisieren. Dazu gibt es doch in VB DIM().

 

-Zahni

[Cybquest 36]

Ich denke, was Power-Kiddy da beschreibt, läuft unter der Rubrik "optionale Parameter", die es in VBScript eigentlich nicht gibt.

Das Hilfskonstrukt über Typename ist interessant, aber eben ein Hilfskonstrukt.

Als "Fehlerbehandlung" würde ich das nicht sehen, denn es fängt ja nur den Fehler des "falschen" Aufrufes ab. Und dafür ist der Programmierer verantwortlich. Leere, falsche oder Null-Daten werden nicht abgefangen.

 

Wenn viel mit optionalen Parametern incl. Standardwerten gearbeitet werden soll, würde sich evtl. auch der Weg über Objekte anbieten.

Z.B. in der Art:

class TestClass
Public varA
Public varB
Public varC

function Out
	if IsEmpty(varA) then varA = "Alfi"
	if IsEmpty(varB) then varB = "Bert"
	if IsEmpty(varC) then varC = "Carl"
 MsgBox "A:" & varA & ", B:" & varB & ", C:" & varC
end function
end class

dim testobj
set testobj = New TestClass
testobj.varA = "Anna"
testobj.varB = "Birgit"
testobj.Out

[Power-Kiddy 10]

Hallo!

 

Ja, der Ansatz mit der Klasse ist gut! Hier beginnen die Vorteile von OOP erkannbar zu werden!

 

...läuft unter der Rubrik "optionale Parameter", die es in VBScript eigentlich nicht gibt.

Nein, nicht ganz!

In der Dokumentation habe ich gelesen daß optionale Parameter NICHT untersützt werden.

Optionale Parameter kann ich (ganz) weg lassen.

Das passiert hier nicht!

Es werden Parameter übergeben, die (eventuell) "Empty" sind, und daher nicht optinal!

 

..Als "Fehlerbehandlung" würde ich das nicht sehen, denn es fängt ja nur den Fehler des "falschen" Aufrufes ab. Leere, falsche oder Null-Daten werden nicht abgefangen.

Ja, dast stimmt. In der Prozedor prüfe ich dann auf Leer oder Falsch.

Die Prüfung auf NULL spare ich mir. Der Type der Variable ist nur dann NULL wenn diese ungültige Daten enthält.

Ich habs bisher nicht geschafft, in die SUB eine Variable/Daten zu kriegen die vom Type NULL sind.

 

Schade das das mit "komplett optionalen Parametern" in VBScript nicht funktionert.

Ich spreche hier von dem Unterschied, daß ich Parameter "andeute" (Komma) oder komplett weg lasse: (sind zwei getrennte Sachen!)

 

Beispiel:

Call TestSUB(A,,C) ' Variable B wird "Empty" übergeben
Call TestSUB()      ' überhaupt keine Varialbe wird übergeben

Sub TestSUB(A,B,C)
...
End Sub

 

Wenn wir von "Optionalen Parametern" Sprechen, dann ist eigentlich das zweite gemeint. Beim ersten Aufruf wird definitiv ein Wert (Empty) übergeben und kann dann "weiterverwarbeitet" werden, soweit das mit Empty eben möglich/sinnvoll ist!

 

Noch was ist mir aufgefallen:

Ich denke daß die Bezeichnungen oft nicht ganz richtig verwendet werden.

Die Parameter beim Aufruf werden "Argumente" genannt.

Parameter heißen die erste dort wo sie übernommen werden (bei der Deklaration der SUB).

 

Ich habe ein Buch über die Programmierung mit Basic vom TI-74 von 1988 gesehen (ist 2, 3 Jahre her) und da stand ein Satz der mir in Erinerung geblieben ist:

Die Parameter in der Parameterliste im Unterprogramm (SUB) müssen mit den Argumenten in der Argumentenliste beim Aufruf übereinstimmen.

Es gab schon damals die Optionen byRef und byVal aber mit einer anderen Syntax:

Bei byVal wurde das Argument (nicht Paremeter) in Klammern gesetzt.

Call SubTest(A,(B),c)

 

Gruß!

Kiddy!

[Cybquest 36]

Es werden Parameter übergeben, die (eventuell) "Empty" sind, und daher nicht optinal!

Wenn da ein Parameter (oder ein Argument) übergeben würde, würde als Type vermutlich nicht "Error" kommen, oder?

OK, bei optionalen Parametern muss auch die Anzahl nicht übereinstimmen, wird jedoch nur das erste und letzte Argument übergeben, müssen entspr. viele Kommas dazwischen. Somit sind wir doch bei opt. Parametern finde ich.

 

Eine weitere Möglichkeit, Argumente wegzulassen um sie in der Sub durch Standardwerte zu ersetzten, wäre in diesem Falle NULL, wenn das sonst eh nirgends vorkommt:

Call Testsub("Anna",NULL,"Carmen") 
Call Testsub("Anna","Birgit",NULL) 

Sub TestSub(A,B,C)
 if (Typename(A) = "Error") OR (TypeName(A) = "Null") then A = "Alfi"
 if (Typename(B) = "Error") OR (TypeName(B) = "Null") then B = "Bert"
 if (Typename(C) = "Error") OR (TypeName(C) = "Null") then C = "Carl"
 MsgBox "A:" & A & ", B:" & B & ", C:" & C
End Sub

[Power-Kiddy 10]

 

Eine weitere Möglichkeit, Argumente wegzulassen um sie in der Sub durch Standardwerte zu ersetzten, wäre in diesem Falle NULL, wenn das sonst eh nirgends vorkommt:

 

Hallo!

 

Ja, das scheint mir am "durchsichtigsten" zu sein und der Ansatz gefällt gut.

Ich hatte nicht daran gedacht, daß ich selbst ja auch NULL übergeben kann.

NULL ist aussagekräftig und kommt mir sonst nicht "in die Quere"!

 

Die kleinen Sachen sind oft genial!

 

An sich ist die Übergabe von Argumenten ja auch keine große Sache.

Wenn mir das logisch und schlüssig scheint dann brauche ich mir später bei der Verwendung kaum noch Gedanken darüber zu machen.

 

Dass es hier verschiedene Denk-Ansätze gibt ist mir klar. Jeder arbeitet eben mit seiner eigenen Erfahrung.

 

Dank Dir!

Kiddy!