API changes

[JoergK]

Hallo,

 

da ich in meinem Projekt die API kritisiert habe, kommt hier ein erster Vorschlag, der noch ausgebaut werden muss. (Konnte nur 10 Minuten dafür aufwenden).

 

Beste Grüße

Jörg

 

IPConnection.cs

DeviceIdentifier.cs

BrickDC.cs

[JoergK]

Und ja, das ganze muss ich noch dokumentieren.

Aber die Nachfrage nach dem Stein meines Anstoßes drohte auszuarten, daher erste schnelle Entwürfe.

Detaillierteres später, sobald ich mehr Zeit habe.

Version.cs

HardwareVersion.cs

FirmwareVersion.cs

[AuronX]

Allgemein

Wenn du nur für dich die Bindings verbessern möchtest (wäre legitim), dann kannst du alles tun was du willst. Bedenke jedoch, dass Verbesserungen für alle (aka. TF übernimmt diese Änderungen) bestimmten Einschränkungen unterliegen:

 

[*]Die Bindings werden automatisch generiert (aus Informationen die für alle Sprachen genutzt werden

[*]Die Methoden eines Brick/Bricklet sind 1:1 Abbildungen dessen was die Hardware bietet, manche Abstraktion bleibt dabei auf der Strecke

[*]TF versucht bei allen Änderungen Abwärtskompatibilität beizubehalten

 

Die Abwärtskompatibilität wird natürlich bei vielen guten Vorschlägen gebrochen. Da muss man schauen ob man TF (und die Nutzer) davon überzeugen kann, dass es das Wert ist. Da ich bereits festgestellt habe, dass auch andere sich Verbesserungen wünschen könnte es ja durchaus eine kritische Masse geben, um einen solchen "Umbruch" zu ermöglichen.

 

Die Frage ist also, ob genügend Leute sich an den Problemen stören, dass ein inkompatibler Umbruch möglich wäre. Ich weiß nicht wie TF dazu steht und wie sehr sich andere an der derzeitigen API stören...

 

Um welche Änderungen geht es?

 

Wenn du nichts dagegen hast würde ich deinen Thread für eine Anforderungsliste missbrauchen (die du gerne auch an die Spitze stellen darfst wenn sie dir gefällt/du sie vervollständigen willst):

• Alles ist ein Interface
  
• enums nutzen anstatt kommentierter ints
  
• Version in eigenen Typ auslagern
  
• UID in eigenen Typ auslagern
  
• ...
  

 

Ich habe diese Liste auch um einen eigenen Vorschlag ergänzt... (auch älter ^^)

 

Enums statt ints

 

Ich hatte hier tatsächlich schon vor Ewigkeiten mal einen Branch rumzufliegen der DeviceIdentifier in den C#-Bindings einführt (hier ist er). Aber ich weiß nicht mehr warum ich aufgehört habe das zu verfolgen.

 

Alles ist ein Interface

 

Für alles interfaces zu erstellen hatte ich auch schonmal im Sinn, habe mich dann aber nicht dazu durchgerungen den Vorschlag einzubringen, weil er hoch inkompatibel wäre, ich wusste damals dass dies so nicht umgesetzt würde...

 

Viele Grüße

Jan

[borg]

Ah, hatte diesen Thread erst übersehen. Ich hab im Prinzip im anderen Thread schon etwas dazu geschrieben: http://www.tinkerunity.org/forum/index.php/topic,2152.msg14230.html#msg14230

[Nic]

Das hört sich alles ganz toll an, man möge aber beachten, das die Bindings mehr die "Rohmasse" sind um eine API auf Low-Level zur HW bereitzustellen. Die Java/Pascal/C#-Bindings müssen dann auch noch harmonisch auf diversen Betriebssystemen Linux/Mac/Win bzw. Frameworks laufen. Da würde ich mit OOP etwas später eingreifen bzw. gibt es keinen Grund der dagegen spricht, sich seinen individuellen, komfortableren Framework selbst um die Bindings zu stricken.

So eine eigene Klasse/Enum der die Konstanten vorhält ist doch nun wirklich schnell geschrieben.

[AuronX]

Ja klar, abgesehen davon, dass es jeder selbst machen muss.

 

Grundsätzlich gestehe ich ja auch ein, dass es Dinge gibt die nicht in die Bindings gehören. Aber von mir oben genannte Punkte sind alle sehr einfach generierbar und ich halte es für eine Altlast, dass sie so sind wie sie sind.

 

edit: Gerade habe ich noch borgs Kommentar im anderen Thread gelesen. Den Teil mit dem "wenig Code aufzwingen" verstehe ich quasi schon. Allerdings sehe ich auch, dass Abweichungen von Sprachkonventionen einem Entwickler dort ebenfalls "Schmerzen" verursachen.

 

Ich habe mich inzwischen damit abgefunden, dass manche Dinge nicht mehr verändert werden... Aber wenn sich herausstellt, dass ich nicht der einzige bin der sich daran stört, dann würde ich einige Änderungen gerne nochmal zur Diskussion stellen ^^

[Nic]

Ja, was solche marginalen Dinge angeht wie eine TVersion auch in C# etc., d.h. wenn strukturell, typmässig die Bindings zw. den Sprachen sich angleichen. Ev. gilt das auch für Out-Parameter, m.E. etwas unhandlich.

 

Andereseits kann jeder sein "Werk" auf GitHub oder hier ins Forum stellen, dass dann in Gemeinschaftsarbeit weitergepflegt wird. Wenn ich mich recht erinnere war das auch mal Dein Vorschlag

[AuronX]

Oh nic das tue ich

 

Du hast mich gerade darauf gebracht, dass mein oben verlinktes Diff sogar einen Pull Request hat Habe den direkt mal aktualisiert ^^

 

https://github.com/Tinkerforge/generators/pull/37

[borg]

@AuronX: Der Pull Request ist nicht abwärtskompatibel, hast du ja auch selbst geschrieben.

 

Interfaces für die Bricks/Bricklets könnte man generieren, das wäre unproblematisch (halte ich aber nicht für kriegsentscheidend).

 

Aber Abstraktionen von Werteeinheiten (wie JoergK es bei der Version gemacht hat) ist echt schwierig. Wir haben ja z.B. an unterschiedlichen Stellen Spannungen, zum Teil mit unterschiedlichen Einheiten (mV, mv/100). Da wäre es ja schön eine Voltage-Class zu haben die das abstrahiert. Allerdings sind diese Art von Informationen aktuell nicht vorhanden.

 

Ein Verbesserungsvorschlag in dieser Richtung sollte also wenn möglich immer mit einer Änderung in der Config anfangen. Also welche Informationen müssen wir in der Config hinzufügen um soetwas generieren zu können? Wie lassen sich diese Informationen in den anderen Sprachen nutzen?

 

Wenn wir da ein gutes Konzept ausgearbeitet bekommen und das Ergebnis was dabei rauskommt hinreichend gut ist um den Aufwand zu rechtfertigen, könnte ich mir gut vorstellen eine neue Version 3.X für alle Bindings zu machen die nicht abwärtskompatibel ist.

[AuronX]

Soetwas habe ich tatsächlich bisher nur in einer eigenen Bibliothek implementiert. Wäre natürlich eine coole Idee sowas direkt in den Bindings zu haben...

 

Distance dist = myBricklet.GetDistance();
if(dist > 20.Millimeters() && dist <= 2.Meters())
{
  //do something awesome
}

 

Ich denke da mal drüber nach... Aber bevor man sowas überall einbaut gibt es glaube ich verschiedene Einzelpunkte, über die man mit vielen Leuten sprechen möchte Ich versuche mal eine Liste zu machen ^^

[JoergK]

Ok, nochmal eine Meinungsäußerung:

 

Wie borg schon sagte: Weniger ist oftmals mehr.

 

Das schließt sein Kommentar bezüglich 'Quellcode' aufzwingen ein, aber auch dass man nicht jede Sprache unterstützen sollte. Lieber eine paar weniger dafür die anderen richtig.

 

Viele der Vorschläge - die nicht nur für C# gut sind - sind meines Erachtens zwingend notwendig, um in den Sprachen ordentlich schreiben zu können.

 

Ich habe mal versucht mir dir Erstellung der C# Bindings anzuschauen. Wenn ich die py's richtig verstehe (hatte bisher keinen kontakt zu schlangen) wird die C# aus anderen py über eine art reflection erstellt. Wenn ja, weerden andere sprachen die eigenarten von python auferzwungen.

 

Ich bin mittlerweile dazu übergegangen, ein adapter pattern zu nutzen. Mal schauen ob das sinn macht.

 

Ach ja, gerne werde ich meine Ideen veröffentlichen. Ich bin auch gerne bereit, dies offen zu diskutieren und gemeinsam etwas sinnvolles auf die Beine zu stellen.

 

beste Grüße

Jörg

[Equinox]

Hallo,

 

dass man nicht jede Sprache unterstützen sollte. Lieber eine paar weniger dafür die anderen richtig.

 

Das sehe ich ganz anders! Ich bin der Meinung, dass TF u.a. deshalb so erfolgreich ist, weil sie eben eine große Zahl an Sprachen unterstützen und noch mehr unterstützen wollen. Jeder hat eine Lieblingssprache und wenn die nicht unterstützt wird, dann ist die Chance, dass man das Produkt kauft schon ziemlich gering. Und wenn es gar die einzige Sprache ist, die man kann, dann wird man das Produkt wohl ziemlich sicher nicht kaufen.

Außerdem ist man manchmal eben durch andere Produkte, mit denen man TF kombinieren will, auf eine bestimmte Sprache angewiesen. Da ist es dann einfach gut, wenn TF nicht der limitierende Faktor ist.

Natürlich sollten die Sprachen auch gut unterstützt werden, aber meiner Meinung nach ist das bei TF ausreichend der Fall. Klar gibt es Dinge, die man bei einzelnen Sprachen verbessern kann, aber bisher konnte ich alles umsetzen, was ich wollte (zumindest bin ich noch nie auf ein Problem bei TF gestoßen, das auf einer "mangelhaften" Umsetzung eines Sprachkonzepts beruhte).

Und jetzt OO-Konzepte krampfhaft überall einzubauen nur um der OO-Willen, halte ich für sinnlos.

[borg]

@JoergK: Die "Config .py's" im Generator sind nur Datenhaltung, sowas wie xml oder json, nur schon direkt vom Python Interpreter parsebar. Wir arbeiten da nicht mit Reflection o.ä.

 

Grundsätzlich ist ein Wrapper der auf der hardwarenahen API liegt aber sicher der am besten gangbare Weg. Wenn möglich könnte man aber trotzdem versuchen den Wrapper so zu gestalten das man ihn auf Dauer eventuell generieren kann.

 

Wir sollten vermutlich die einfach generierbaren Änderungen alle sammelt (enums, interfaces etc). Wir haben dann irgendwann eine hinreichend große Menge von Änderungen um eine neue API-brechende Version zu machen. Nur für Enums oder nur für Interfaces würde man nicht die API brechen.

[JoergK]

Hallo,

 

a) ich habe nie verlangt eine neue 'API' zu bekommen

b) da mir die bindings aus software-architektur sicht nicht ausreichen, habe ich beschlossen, mir eine neue zu schreiben.

c) Anscheinend ging es aber nicht nur mir so, daher dieser ausufernde Thread.

d) ich weiss das Software wie babies sind. Kritisiert man meinen Sohn kritisiert man meist auch mich persönlich.  Das ist menschlich, nur bedarf es einige jahre (war bei mir so) dies beruflich gesehen loszuwerden.  Daher nehmt auch gerade aus getätigte aussagen nicht persönlich.

e) ich finde die wertigkeit der tf hardware hat auch eine professionelle sw verdient. Daher wäre meines Erachtens eine gute Unterstützung von einer handvoll sprachen besser als alle möglichen eher schlecht zu unterstützen.  Klar kann man mit den Bindings alles machen. Hier unterscheide ich aber zwischen Hobby bereich und professionellen bereich. Da TF auch kommerziell arbeitet (finde ich ha auch gut) sollten die bindings auch prof. sein.

 

Again just my 2 cent. Jeder hat seine Meinung und ich finde wir sollten aufhören darüber endlos zu diskutieren. Vielleicht finden sich hier ein paar gleichgesinnte und wir stellen gemeinsam was auf die Beine. Das ganze muss dovh nicht morgen umgesetzt werden. Das sollte hier nzr als Anregung dienen und nicht als API sofort ersetzen thread...

[Equinox]

Hallo,

 

... als alle möglichen eher schlecht zu unterstützen.

 

Zugegebenermaßen kenne ich nicht alle Bindings von TF, aber die "schlechte Unterstützung" sehe ich absolut nicht. Da TF ja auch schon vielfach im professionellen Bereich eingesetzt wird, scheint die Unterstützung auch dafür zu reichen.

Klar bin ich auch für Verbesserungen, aber was ich bisher gelesen habe überzeugt mich nicht bzw. rechtfertigt in meinen Augen nicht, von "schlechter Unterstützung" zu reden.

[raphael_vogel]

Ich finde es gibt wesentlich wichtigere Themen die TF angehen sollte/könnte wie z.B. neue Bricks/Bricklets (Chibi Nachfolger, RED Brick.....).

 

Bei einer 4 (oder sind es 5) Mann Firma muss man sich auf Dinge konzentrieren, die auch Umsatz erzeugen. "Schönere" Bindings führen zur Zeit sicherlich nicht zu mehr Umsatz oder größerem wirtschaftlichen Erfolg.

 

Also wem die Bindings nicht genügen der soll halt die TF API verschalen und seine eigene API drüber bauen.

 

Und ja ich bin auch schon über 15 Jahre im Software Geschäft und weiss dass Produkte nicht verkauft werden oder anklang finden, weil sie so eine schöne OO Architektur haben. Hab schon zu viele schön designte Software sterben sehen ;-)

[Equinox]

Meine volle Zustimmung!