Out-Parameter in C#-Bindings

[AuronX]

Hiho, ich habe festgestellt, dass die Getter in den C#-Bindings alle diese Form haben (Beispiel aus dem BrickletHumidity):

		public void GetHumidity(out ushort humidity)
	{
		//Anfrage bauen

		ipcon.Write(this, data_, TYPE_GET_HUMIDITY, true); //senden, hierbei wird das writeEvent aquired

		byte[] answer;
		//antwort in answer speichern

		humidity = LEConverter.UShortFrom(4, answer);

		writeEvent.Set(); //writeEvent wird released
	}

 

Insbesondere wundert mich, dass dadurch alle Getter über out-parameter funktionieren und nicht über Rückgabewerte. Im Prinzip wäre ja die Zeile

humidity = LEConverter.UShortFrom(4, answer);

auch durch

return LEConverter.UShortFrom(4, answer);

ersetzbar. Das einzige was sich ändern würde ist, dass jetzt das writeEvent schon vor dem return released werden müsste. Das ist aber eh sinnvoll, da ja der kritische Teil der Zugriff auf die TCP-Connection ist. Die Benutzung des LEConverter muss nicht synchronisiert werden.

 

Insofern würde mich interessieren, was die Motivation hinter der Benutzung der out-paramter ist und ob es nicht sinnvoll wäre, Rückgabewerte zu nutzen.

 

Viele Grüße

Jan

[photron]

C# kann nicht mehrere Werte zurückgeben wie das z.B. Python recht einfach erlaubt.

 

Daher verwenden wir in C# generell out Parameter statt die Ergebnisse direkt zurück zu geben.

 

Bei BrickletHumidity.GetHumidity könnte man hier den einen Wert direkt zurück geben, aber BrickIMU.GetQuaternion hat 4 Rückgabewerte, daher der allgemein Weg über die out Parameter.

[Nic]

Also beim Brick-Stepper sehe ich keinen Grund pauschal out-Parm. zu verwenden, dort werden zB. bei GetMaxVelocity oder GetCurrentVelocity jeweils nur ein Wert zurückgegeben.

 

D.d. bei Phyton so möglich oder üblich ist, sollte in der Folge aber nicht für andere Programmiersprachen übertragen werden. Dort bitte Rücksicht auf deren Eigenheiten bzw. Paradigmen nehmen.

 

Im Falle des IMU könnte man aber genausogut eine neue Klasse schaffen bzw. ein Array verwenden, die als Rückgabewert die 5 Floats kapselt.

[borg]

Insofern würde mich interessieren, was die Motivation hinter der Benutzung der out-paramter ist und ob es nicht sinnvoll wäre, Rückgabewerte zu nutzen.

Die Motivation war einfach eine konsistente API zu haben und nicht einen Teil per out-Parameter und einen Teil ohne out-Parameter zurück zu geben.

 

Alternativ hätte man höchstens structs machen können, aber da C# out-Parameter als Feature bietet haben wir es halt genutzt.

 

@Nic: Wir haben ja das Python Paradigma gerade nicht übertragen (da hätten wir dann structs nehmen müssen) sondern haben ein C# Paradigma genommen (out-Parameter).

[AuronX]

Okay, die mehrfach-rückgaben habe ich nicht berücksichtigt. Mein persönlicher Favorit wären zwar wahrscheinlich eigene Typen, aber der gewählte Ansatz ist zumindest konsistent (und gut generierbar).

 

Danke für die Antwort^^

 

LG

Jan

[Nic]

@Olaf

Da hat M$ eben gepennt, dass C# sowas zulässt Und in der Konsequenz muss so ein schlechtes Paradigma, auch wenn die Sprache es hergibt, nicht unbedingt pauschal bei allen Methoden genutzt werden, egal ob es in Phyton-Welt so üblich ist. Beruflich und privat sind mir out-Parameter in C# äußerst selten begegnet.

 

Während der Anwendungsentw. vom Stepper habe ich erstmal die Klasse abgeleitet und umständlich zusätzliche Funktionen geschaffen, um in der Anwendung zahlreiche Werte als Status per Einzeiler zurückzugeben. Ich sehe einfach keinen Sinn, Methoden die jeweils nur 1 Rückgabewert eines einfachen Typen liefern als Prozedure statt Funktion anzubieten.

[AuronX]

@Nic: Ich bin auch kein Fan von Out ^^ Andererseits bin ich es gewöhnt fremde Interfaces durch eigene wegzukapseln.

 

Möglicherweise macht es aber auch Sinn eigene Bindings für beliebte Sprachen zu entwickeln (innerhalb der Community). Weil die default bindings halt immer nen Kompromiss zwischen gutem Generator-code und gutem Binding-Code darstellen müssen. Es würde zum Beispiel den Generator ziemlich aufblasen, wenn man überall korrekte Range-Checks einbaut. Dennoch wären diese schon sinnvoll. Selbst geschriebener Code kann sich da deutlich besser "anpassen".

 

Allerdings weiß ich nicht ob es im oder entgegen dem Interesse von TF wäre, wenn man soetwas entwickeln würde.

 

P.S.:

Da hat M$ eben gepennt, dass C# sowas zulässt

 

Ich finds schon ganz Okay. Bei C# geht man von einem verantwortungsbewussten Entwickler aus, während Java eher den Ansatz verfolgt alles was missbraucht werden könnte nicht zu unterstützen. (mein Empfinden)

[Nic]

Das würde eine 2.Baustelle aufmachen, die TF-API nochmals zu kapseln, um z.B. strukturelle Schwächen zu beseitigen !?

Und wer pflegt das ganze dauerhaft ? Praktischer wäre die notwendigen Anpassungen im Code-Generator vorzunehmen.

 

Die Kapselung/Interfaces kann jeder später je nach Anwendungsfall für sich machen.

 

 

[AuronX]

Das mit der 2. Baustelle ist schon richtig... deswegen meinte ich auch nur bei "beliebten" Bindings... naja mal schauen... irgendwas werde ich mir auf jeden Fall einfallen lassen für das Zeug woran ich arbeite... entweder ich Kapsel die Original-Lib oder ich bau auf deren Quellcode neu. Mal gucken ^^

 

Bis bald

Jan

[Nic]

Finde ich klasse, dass Du Dir Mühe machst, strukturelle Verbesserungen zu machen. Nur würde ich empfehlen, dass gleich in den Beschreibungsdateien vom Code-Generator zu machen.

Bin mir aber nicht ganz sicher, wie einfach das ist, noch ob die Mannschaft von TF das so gerne sieht 

[borg]

Über patches sind wir natürlich immer Dankbar, ich hab gerade erst noch ein merge request betreffend der C# Bindings bei github gepulled: https://github.com/Tinkerforge/generators/pull/3

 

Falls die Änderung etwas an der nach außen sichtbaren API ändert ist die Hürde das ich so ein patch annehme natürlich größer, da muss es sich dann schon wirklich lohnen (Es muss dann ja schließlich jeder Kunde seinen Code ändern wenn er updated)!

[AuronX]

Der patch war übrigens von mir (große vielfalt an Nicknames ^^)

 

Ich denke das nächste Mal werde ich dann aktiv wenn ich das erste bisschen gebastelt habe, da fallen mir dann bestimmt wieder irgendwelche Sachen auf. Auf jeden Fall schonmal großen Dank für eure offene Arbeitsweise (Blogging über Fortschritt, Open-Source), so macht das ganze deutlich mehr Spaß ^^

[photron]

In C# Bindings Version 1.1.0 geben jetzt u.a. Methoden mit nur einem Ausgabewert diesen per return zurück. Die alten Versionen der Methoden mit einem out-Parmeter sind weiterhin verfügbar und als obsolete markiert. Bei mehr als einem Ausgabewerten werden weiterhin all per out-Parameter zurückgegeben.

 

Dank an AuronX, der diese Änderung beigesteuert hat

[The_Real_Black]

Top! Gleich die neuen Bindings ziehen ^^