Jump to content

Recommended Posts

Geschrieben

Ich versuche mal die Diskussion über API-Änderungen zu strukturieren, indem ich für dieses Thema einen eigenen Thread eröffne.

 

Idee

Die Tinkerforge-API sollte Einheiten nativ unterstützen, um so die Arbeit zu erleichtern und die Selbstdokumentation des Codes zu verbessern.

 

Beispiel

(dient nur dazu die Idee zu verdeutlichen, kann vom Endergebnis abweichen)

 

Distance distance = myBricklet.GetDistance();
if(distance > 20.Millimeters() && distance <= 2.Meters())
{
  Console.WriteLine("Die Distanz beträgt {0} Zentimeter", distance.InCentimeters);
}

 

Überlegungen

Um soetwas zu unterstützen müssen verschiedene Dinge getan werden:

  • Die Konfigurationen der Bricklets müssen die Einheiten der Werte kennen (Hat nur etwas mit den Bindings zu tun, keine Auswirkungen auf Speicherplatz o.ä. auf den Bricklets)
  • Die unterstützten Einheiten müssen in allen (vorgesehenen) Sprachen einen eigenen Typ (Klasse/Struct) haben

 

Frage 1: Generieren oder selber bauen?

 

Die erste Frage die ich mir stellen würde:

Werden die Typen der Einheiten generiert oder manuell erstellt?

 

Beim Generieren sehe ich den Vorteil darin, dass es vermutlich einfacher umzusetzen ist. TF definiert einmal (ähnlich wie bisher für Bricklets) einen Satz an Einheiten und dann werden dafür Typen erzeugt. Das funktioniert vermutlich deswegen leicht, weil Einheiten immer gleich sind:

 1 km = 1000 m
1000 mm = 1 m

1 kV = 1000 V
1000 mV = 1 V

 

Allerdings denke ich, dass man bei händischen Implementierungen Korrelationen zwischen Einheiten besser abbilden kann. Also dass man beispielsweise Volt und Ampere multiplizieren kann. Ich wüsste nicht, wie ich das in eine generische Konfiguration schreiben wollte.

 

Frage 2: Was ist die Basiseinheit?

 

Wie auch immer diese Klasse (z.B. Distance) erzeugt wird, sie muss den aktuellen Wert (etwa die Entfernung) speichern. Ich habe mich dafür entschieden (in meiner Bibliothek), dass ich die Entfernung als Integer speichere und damit die Länge in Millimetern zähle.

 

Die Folgen dieser Entscheidung:

  • Ich werde niemals genauere Auflösungen als mm unterstützen
  • Die maximale Distanz beträgt ca. 2000 km (das Maximum von Int32 in Millimetern)
  • Alle Distanzen (unabhängig von der Sensorauflösung) belegen 4 Byte Arbeitsspeicher (Kritisch bei embedded Anwendungen?)

 

Für mich ist das nicht kritisch, notfalls ändere ich diesen Typ so wie ich es brauche. Wenn TF das in die API einbaut, dann ist das in Stein gemeißelt... Choose wisely!

 

Frage 3: Alle Sprachen unterstützen?

 

Sollen die Bindings für alle Sprachen solche Dinge unterstützen? Ich weiß es nicht... Ich kann mir nicht vorstellen, dass es in den C-Bindings mehr Spaß macht mit solchen nativen Typen zu arbeiten...

 

Andererseits waren bisher alle Bindings möglichst identisch... würden dadurch Unterschiede eingeführt die schlecht sind?

 

Es gibt halt Sprachen, bei denen sich Einheiten wirklich gut lesbar einbauen lassen (C#-Beispiel siehe oben... noch besser: Ruby) und es gibt Sprachen, bei denen ich befürchte, dass es einfach alles nur schlimmer machen würde ©.

 

Frage 4: Besteht überhaupt Bedarf/Nachfrage?

 

Wichtige Frage... Vielleicht will das auch gar keiner...

 

Das sind die Diskussionspunkte die mir unmittelbar eingefallen sind. Bestimmt gibt es noch mehr Diskussionspunkte zu diesem Thema.

 

Meine persönliche Meinung werde ich (sofern es mir gelingt) aus diesem Posting heraushalten und nur in einer Antwort präsentieren.

Geschrieben

Zu Frage 3: Hier ist meine persönliche Meinung, dass Einheiten nicht auf allen Sprachen implementiert werden sollten, weil sie nicht überall Sinn machen.

 

Ich würde sie nur in den Sprachen unterstützen, die es leicht machen sie auch bequem zu benutzen. Damit verzichtet man natürlich auf Einheitlichkeit zwischen den Bindings, aber ich habe die Befürchtung, dass diese Einheitlichkeit mehr kostet, als dass sie etwas nützt.

 

Zu Frage 4: Für mich ja!

 

Frage 2 muss Je nach Einheit diskutiert werden und bei Frage 1 würde ich auch lieber Feedback abwarten bevor ich mich äußere :D

Geschrieben

Hallo zusammen,

ich komme eher aus der Java Richtung und habe mittelmäßige Erfahrungen in den Programmiersprachen. Dennoch möchte ich mal aus meiner Anwendersicht etwas zu dem Thema sagen:

Die Dokumentation, also unter http://www.tinkerforge.com/de/doc/index.html finde ich eigentlich gut, ab und an fehlen vielleicht einige Hinweise für Anfänger (ich kann nur für die Java Doku sprechen). Die Stellen kann ich gerne mal nachholen (TF reagiert bei Hinweisen auch immer sehr schnell und pflegt die Änderungen ein!). Ansonsten finde ich die Beispiel für die Bricks und Bricklets sehr gut. Das der automatisch generierte Code nicht kommentiert ist, naja das ist mir nicht aufgefallen, da ich selbst die Bindings nicht anfassen möchte. Beispiele sind grundlegend kommentiert.

 

Zur Funktionalität der Getter und Setter etc. kann ich nur sagen, dass an einigen Stellen auffällt,  wenn mal ints mal shorts zurück gegeben werden, dass hätte man evtl. vereinheitlichen können.

 

Ansonsten finde ich die vorhandene API und den Gedanken dahinter sehr gut!

TF macht es möchte auf alle Hardware Funktionen zu zugreifen. Für weitere Funktionen, Ableitungen oder ähnliches kann der User seine eigenen Ideen darüber bauen. Und ich denke, dass das auch die Idee dahinter ist. Denn umso mehr man hineinbaut umso mehr wird es auch eingeschränkt. So ist es jeden selbst überlassen mit den angebotenen Werten so zu arbeiten wie man es benötigt.

 

Alles nur aus meiner Anwendersicht gesprochen.

 

Grüße

Unex

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...