4. Beta-Tester für C++11 UML State Machine Framework yasmine gesucht

Beta-Tester für C++11 UML State Machine Framework yasmine gesucht

  • V

    Artchi schrieb:

    Also Open Source ist sie nach OSI-Definition jedenfalls nicht! Die MIT-Lizenz und eure Lizenz beißen sich!

    Welcher der 10 Punkte ist verletzt?

    Artchi schrieb:

    Das was du uns "verkaufen" willst, ist sowas wie eine SharedSource-Lizenz. Aber ganz bestimmt nicht eine OSI-konforme-Lizenz.

    Also eigentlich habe ich nach Beta-Testern gesucht und gehofft, dass es mal jemand ausprobiert und technisches Feedback gibt. So hatte ich es von der Forum-Community erwartet, wie ich sie mal kannte. Eine Lizenzhexenjagd hatte ich nicht erwartet.

    Artchi schrieb:

    Eigentlich habt ihr eine Dual-Lizenz. Der User kann sich die Lizenz anscheinend aussuchen, womit dann die andere jeweils ungültig wird. Irgendwie totaler Quatsch was ihr da macht.

    😕
    Das ist jetzt totaler Quatsch, was Du da schreibst.
    Eine Lizenz ist für nicht-kommerziellen Gebrauch und eine für kommerziellen Gebrauch.

    0
  • A

    void* schrieb:

    Artchi schrieb:

    Also Open Source ist sie nach OSI-Definition jedenfalls nicht! Die MIT-Lizenz und eure Lizenz beißen sich!

    Welcher der 10 Punkte ist verletzt?

    Du verletzt mit eurem Lizenztext und hier von dir nochmal formuliert:

    void* schrieb:

    Eine Lizenz ist für nicht-kommerziellen Gebrauch und eine für kommerziellen Gebrauch.

    den Punkt 6!

    Die OSD sagt eindeutig, das keine Gruppen (Religion, Ethnie etc.) (Punkt 5) und auch keine private/kommerzielle Benutzung ausgeschlossen werden dürfe (Punkt 6).

    Und in der MIT-Lizenz steht davon auch nichts. Aber ihr hebt es mit eurem Lizenztext wieder auf.

    Außerdem verltezt ihr noch andere OSD-Punkte, und somit die MIT-Lizenz:

    void* schrieb:

    Außerdem ist in dem "Blödsinn" z.B. geregelt, dass man die Bibliothek an sich nicht weitervertreiben darf. Wenn jemand mit der Bibliothek Geld verdienen will, dann will ich auch die Hand aufhalten.

    Verstoß gegen Punkt 1!

    Meiner Meinung nach habt ihr euch nicht ausreichend mit den FSF/OSI-Lizenzen auseinander gesetzt. Ihr wollte auf der OSS-Welle mitsurfen, ohne aber OSS zu akzeptieren. Natürlich gibt es da eine Hexjagd. Weil keiner will sich gerne auf den Arm nehmen lassen. Und hier im Forum sind genug Menschen, die lange genug Erfahrung in der IT und FSF/OSI haben.

    So wie ich es sehe, wäre für euch eine Dual-Lizenz mit GPL und Closed-Source besser. Aber die MIT mit Closed-Source macht absolut keinen Sinn.

    0

  • Artchi schrieb:

    Closed-Source

    Hä?

    0
  • A

    hustbaer schrieb:

    Artchi schrieb:

    Closed-Source

    Hä?

    Ja, meinet wegen nenne es Proprietäre Lizenz. Er kann sein Produkt parallel als Closed Source vertreiben und für die ClosedSource-Variante als Topping noch ein paar Features dort einbauen, die die OpenSource-Variante nicht hat.

    Er kann als Urheber für seine Kunden/User ja zwei Lizenzen anbieten: eine GPL für die, die kein Problem damit haben (weil sie eh GPL/OpenSource-Produkte entwickeln). Und alternativ eine Proprietäre Lizenz für die, die mit dem Copyleft ein Problem haben (meist weil sie Closed-Source-Produkte entwickeln), können bei ihm einen anderen Vertrag abschließen. Er hat als Copyright-Inhaber die Macht und Freiheit über seine Lizenzen zu bestimmen. Aber nicht alle Kombinationen machen Sinn (MIT und Proprietär ist unsinnig, erst Recht nicht wenn die Leistung/Inhalt 1:1 gleich ist).

    Gutes Beispiel ist Qt: die machen GPL bzw. LGPL, und bieten noch eine andere Lizenz für ClosedSource-Produkte an um garantiert Geld mit Qt zu verdienen (was bei GPL/LGPL nicht sicher ist).

    Also das was auch void eigentlich erreichen will. Nur wird er trotzdem nicht Punkt 1 und 6 der OSD vermeiden können: entweder steht er hinter dem FSF/OSI-Gedanken oder nicht.

    0
  • V

    Artchi schrieb:

    Die OSD sagt eindeutig, das keine Gruppen (Religion, Ethnie etc.) (Punkt 5) und auch keine private/kommerzielle Benutzung ausgeschlossen werden dürfe (Punkt 6).

    Und in der MIT-Lizenz steht davon auch nichts. Aber ihr hebt es mit eurem Lizenztext wieder auf.

    Das ist nun IMHO haarspalterisch. Es ist zwar richtig, dass die eine Lizenz eine Gruppe ausschließt, die andere Lizenz schließt aber genau diese Gruppe ein.

    Artchi schrieb:

    Außerdem verltezt ihr noch andere OSD-Punkte,

    void* schrieb:

    Außerdem ist in dem "Blödsinn" z.B. geregelt, dass man die Bibliothek an sich nicht weitervertreiben darf. Wenn jemand mit der Bibliothek Geld verdienen will, dann will ich auch die Hand aufhalten.

    Verstoß gegen Punkt 1!

    Punkt1 schrieb:

    aggregate software distribution containing programs from several different sources

    Für mich steht hier etwas von "Teil einer Distribution, die Programme aus verschiedenen Quellen" enthält. Wo steht in unserer Lizenz, dass die Bibliothek nicht Teil eines Programms sein darf, das gegen Entgeld vertrieben werden darf? Ich kann hier nicht rauslesen, dass man das Stück Software (hier: die Bibliothek) für sich alleine verkaufen können muss.
    **
    Edit:**
    Ok, es ist wohl so, dass die mit "program" z.B. auch eine Bibliothek meinen. Dann hast Du in diesem Punkt recht.

    Edit 2:
    Obwohl...da steht "aggregate" und "component". Die "Bibliothek als Teil von etwas", die Bibliothek alleine ist kein Teil/Komponente von einer Zustammenstellung, oder?

    Artchi schrieb:

    Ihr wollte auf der OSS-Welle mitsurfen, ohne aber OSS zu akzeptieren. Natürlich gibt es da eine Hexjagd. Weil keiner will sich gerne auf den Arm nehmen lassen.

    Das ist jetzt eine Unterstellung. Ich habe ein Stück Software, das ich geteilt habe, weil es vielleicht jemandem nützlich sein kann und ich im Gegenzug von dem Feedback profitieren kann (gefundene Bugs, Feature-Ideen, ...).
    Aber natürlich steckt eine böse Absicht dahinter.

    0
  • V

    Artchi schrieb:

    Also das was auch void eigentlich erreichen will.

    Da verstehst Du was falsch. Ich will mit der Bibliothek selber überhaupt kein Geld verdienen (im Gegensatz zur Qt Company mit Qt). Ich will _nicht_, dass jemand meine Bibliothek nimmt, die ich _umsonst_ anbiete und diese dann _verkauft_. Das ist alles. Punkt.

    0
  • A

    void* schrieb:

    Artchi schrieb:

    Also das was auch void eigentlich erreichen will.

    Da verstehst Du was falsch. Ich will mit der Bibliothek selber überhaupt kein Geld verdienen (im Gegensatz zur Qt Company mit Qt). Ich will _nicht_, dass jemand meine Bibliothek nimmt, die ich _umsonst_ anbiete und diese dann _verkauft_. Das ist alles. Punkt.

    OK, habe ich erst anders verstanden. Ändert aber nichts: denn genau das erlaubt die MIT-Lizenz und ist auch die Parole von FSF und OSI. Jeder soll mit OSS/FSF-Software Geld verdienen können, wenn er das kann und sich an die Lizenzbedingungen hält (bei Yasmin halt an der MIT-Lizenz). Wenn du das nicht willst, solltest du dich von der MIT-Lizenz trennen.

    Mir ist nur schleierhaft, wie du gerade auf die MIT-Lizenz gekommen bist? Das ist gerade die, die es am einfachsten macht, das andere Geld verdienen können. 😕 Wenn es wenigstens die LGPL, GPL, MS-RL oder andere Copyleft-Lizenz gewesen wäre, hättest du es den anderen wenigstens etwas schwerer gemacht, das sie damit "einfach so" Geld verdienen können (verhindern kannst du es aber nicht).

    Egal was du uns hier noch erzählst, hinter dem Opensource-Gedanken stehst du jedenfalls nicht.

    0
  • V

    Artchi schrieb:

    Mir ist nur schleierhaft, wie du gerade auf die MIT-Lizenz gekommen bist?

    Weil sie unrestriktiv ist und ich genau die eine Einschränkung haben wollte. Und sie ist nicht "copyrighted", also darf man sie modifizieren. Mehr steckt da nicht dahinter.

    Artchi schrieb:

    Egal was du uns hier noch erzählst, hinter dem Opensource-Gedanken stehst du jedenfalls nicht.

    Das ist natürlich eine scharfe Abgrenzung. Aber nein, in der 100%-Hardliner-Ecke stehe ich nicht (so wie ich selten etwas schwarz oder weiß sehe). Habe ich aber auch nie behauptet. Aber in die fiese Ausbeuter-böse Menschen-Ecke musst Du mich auch nicht stellen.

    0
  • A

    Wenn jemand mit Begriffen wie OpenSource und sogar MIT-Lizenz ankommt, dann muss er das auch liefern. Oder?

    Und nein, ich verlange kein OpenSource von jemandem um ihn als "gut" anzusehen. Kann jeder SharedSource oder Closed Source machen wie er will! Das ist völlig legitim! Ich bin auch kein OSS/FSF-Jünger, ich benutze MS-Windows und VisualStudio. Aber MS verkauft mir das nicht als OpenSource sondern ganz klar als ClosedSource. Jeder potenzielle Interessen weiß woran er ist. 👍

    Und wir sind auf Seite 5 deines Threads, in dem du uns immer noch dein Yasmine felsenfest als OpenSource "verkaufen" willst... geht gar nicht.

    0
  • V

    Artchi schrieb:

    Und wir sind auf Seite 5 deines Threads, in dem du uns immer noch dein Yasmine felsenfest als OpenSource "verkaufen" willst... geht gar nicht.

    Womit mache ich das denn? Wann habe ich das dann gesagt?
    Wenn Du den ersten Teil der Diskussion mitverfolgt hättest, wäre Dir vielleicht aufgefallen, dass ich auf die dort geäußerte Kritik IMHO sehr offen eingegangen bin (obwohl die Kritik teilweise hart an der Grenzen der Sachlichkeit war) und schon Diverses angepasst habe. Dass Du jetzt so tust als würde ich seit 5 Seiten auf meinem Standpunkt beharren, finde ich nicht in Ordnung.

    Auch dass Du das Ganze jetzt so kategorisiert, als wäre es mehr "closed" als "open" finde ich auch nicht in Ordnung.

    Umsonst und offen ist nicht umsonst und offen genug.
    Um die Analogie von vorhin aufzugreifen:
    Auf mein Klo gehen reicht nicht, auch noch das Wunschklopapier muss es sein.

    0

  • @void*
    Nenn die Lizenz einfach anders. z.b. SOS - kurz für "Seadex Open Source".
    Und "bewirb" die Lizenz nicht damit sie als MIT Lizenz anzupreisen. Eher mit sowas wie "relativ liberale Lizenz die auf der MIT Lizenz basiert".

    @Artchi
    Deine enge Auslegung des Begriffs Open Source ist mMn. total unangebracht. Es gibt schliesslich nicht umsonst Begriffe/Kürzel wie FOSS.

    0
  • V

    hustbaer schrieb:

    @void*
    Nenn die Lizenz einfach anders. z.b. SOS - kurz für "Seadex Open Source".
    Und "bewirb" die Lizenz nicht damit sie als MIT Lizenz anzupreisen. Eher mit sowas wie "relativ liberale Lizenz die auf der MIT Lizenz basiert".

    Es war nie mein Ziel damit zu "werben". Mir ging es nur darum zu zeigen, dass man damit fast alles machen darf und dass die proprietäre Lizenz (das habe ich offen gesagt, dass sie das ist) eine wichtige Einschränkung enthält (und auch welche). Das Ganze war ein Satz im Eröffnungspost. Danach bin ich nie - wie unterstellt - darauf rumgeritten, sondern habe mich zu den Kritikpunkten aus meiner Position geäußert. Auch habe ich nie etwas zu verschönigen versucht oder gesagt "doch, doch, dass ist OpenSource". Ich habe nur die Position vertreten, dass die Lizenz sehr liberal ist. Und das ist sie IMHO auch.
    Mir kam in der Diskussion jetzt auch schon die Idee die MIT einfach zu übersetzen, als extra Paragraph einzubetten und den Verweis auf die MIT-Lizenz ganz zu entfernen.

    0
  • T

    void* schrieb:

    Jegliches Feedback über API, Bugs und auch Feature-Requests sind willkommen.

    Ich habe nur mal ein kurzen Blick in das Beispiel geworfen:

    - Seit Ihr euch sicher, dass ihr jedem Benutzer eurer Bibliothek die Nutzung eures Loggings aufzwingen wollt? Das erschwert die Integration.
    - Ungarische Notation ist so etwas von out! Das erschwert das Lesen von Code ungemein.
    - Brauche ich wirklich 10 header um ein Minimal-Beispiel zu schreiben?
    - Sehr rigoroser Gebrauch von Pointern. Ist das wirklich nötig? Warum kann ich einen state machine nicht einfach als value verwenden?
    - Idealerweise würde ich überhaupt keinen dynamischen Speicher brauchen.
    - Y_UNUSED_PARAMETER: warum gebt Ihr Parametern erst Namen um die Nicht-Verwendung dann mit einem Makro zu dokumentieren?
    - Was sollen regions sein und warum funktioniert ein einfaches Beispiel nicht ohne?
    - return ist KEINE FUNKTION! 😉
    - usw.

    also wenn ich mir schon die Mühe machen würde, für Zustandsautomaten eine Library zu schreiben, dann:
    - Muss sie das Erstellen eines Automatens auch _deutlich_ vereinfachen.
    - Muss der Automat also solches sehr gut lesbar sein, da meiner Meinung nach, genau dass das Problem von Automaten ist: Sie werden schnell unübersichtlich.

    Beispiel:

    #include <state_foo>
#include <iostream>

enum state_codes {
    waiting,
    reply
};

enum event_codes {
    hello
};

state_machine< state_codes, event_codes >(
    state( waiting,
        transition< hello, reply >(),
        on_enter(
            [](){ std::cout << "waiting..." << std::endl; }
        )
    ),
    state( reply,
        auto_transiton< waiting >(),
        on_enter(
            [](){ std::cout << "Hello, foo!" << std::endl; }
        )
    )
) pointless_example_machine;

int main()
{
    pointless_example_machine.fire_event( hello );  
    pointless_example_machine.fire_event( hello );  
    pointless_example_machine.fire_event( hello, std::clog ); // hier mal mit logging
}

    mfg Torsten

    0
  • V

    Hallo Torsten,

    Torsten Robitzki schrieb:

    void* schrieb:

    Jegliches Feedback über API, Bugs und auch Feature-Requests sind willkommen.

    vielen Dank schon mal für Dein Feedback!

    Torsten Robitzki schrieb:

    - Seit Ihr euch sicher, dass ihr jedem Benutzer eurer Bibliothek die Nutzung eures Loggings aufzwingen wollt? Das erschwert die Integration.

    Das ist nicht erzwungen, sondern optional. Das muss man nicht nutzen. Wenn Du nichts initialisierst, wird auch nichts geloggt.
    Eine Idee habe ich aber noch zusätzlich:
    Wir werden noch ein Macro/Define einführen, mit dem man erreichen kann, dass die Log-Macros gar keinen Code erzeugen.

    Torsten Robitzki schrieb:

    - Ungarische Notation ist so etwas von out! Das erschwert das Lesen von Code ungemein.

    Also ungarische Notation kann man das nun wirklich nicht nennen. Hier wird ja keine Typinformation in Variablennamen codiert. Sonst benutzt auch Qt wegen dem Q vor den Klassennamen ungarische Notation.
    Und ich selber sehe gern den Scope einer Variablen am Namen (Klassen-Member, Funktionspararmeter, global, lokal, ...).
    Bei Typen finde ich es u.a. hilfreich
    - wegen Interfaces: i_printer und t_printer oder printer_interface und printer?
    - weil öfters Variablennamen dem Typ "entsprechen". Dann muss man sich für den Variablennamen nicht künstlich irgendwelche Prosa ausdenken.

    void check_consumable_levels(const t_printer& p_printer) {
	// ...
}

    void check_consumable_levels(const printer& printer_to_check) {
	// ...
}

    Im Code selber kommt noch zu oft l_ vor. Das sollte eigentlich nur in Sonderfällen zur Auflösung von Mehrdeutigkeiten dienen. Das werden wir noch ausmisten.

    Torsten Robitzki schrieb:

    - Brauche ich wirklich 10 header um ein Minimal-Beispiel zu schreiben?

    Ja und nein. Technisch gesehen ja, weil man halt diverse verschiedene Klassen verwendet. Aus der Usability-/Convenience-Sicht nein, denn es könnte natürlich für die Bibliothek einen Sammel-Header à la windows.h geben. Ggf. auch mit einem "lean and mean"-Macro, das dazu führt, dass nur die wichtigsten Features mitliefert werden.
    Ich nehme das auf.

    Torsten Robitzki schrieb:

    - Sehr rigoroser Gebrauch von Pointern. Ist das wirklich nötig? Warum kann ich einen state machine nicht einfach als value verwenden?
    - Idealerweise würde ich überhaupt keinen dynamischen Speicher brauchen.

    Bzgl. der State Machine:
    Natürlich steht Dir frei die State Machine auf dem Stack anstatt auf dem Heap anzulegen. In dem Beispiel ist es so gelöst, da die State Machine in einer Factory-Funktion erzeug wird und die State Machine ohne kopieren durch reines moven des unique_ptr herausgegeben werden kann.
    Du könntest die State Machine aber auch als Klassenmember haben oder in eine Factory-Funktion per Referenz rein reichen und befüllen lassen. Eine State Machine (rekursiv) zu kopieren halte ich (als default-Verhalten) für keine gute Idee.
    Bzgl. der internen Verwendung:
    Das ist zum Teil so, weil intern polymorphe Container verwendet werden und zum Teil weil im großen und ganzen gegen Interfaces anstatt gegen Implementierungen gearbeitet wird.

    Torsten Robitzki schrieb:

    - Y_UNUSED_PARAMETER: warum gebt Ihr Parametern erst Namen um die Nicht-Verwendung dann mit einem Makro zu dokumentieren?

    Bei der Lambda beim Erstellen der State Machine ist das vielleicht ein etwas schweres Geschütz. Aber das Stichwort "dokumentieren" ist genau das richtige.
    Während das einfache Weglassen des Parameters es implizit macht, passiert es durch das Macro explizit. Außerdem läßt sich nach dem Macro gut suchen, nach einem weggelassenen Parameter nicht. Dies ist ja auch _ein_ Vorteil von C++-Casts gegenüber C-Style-Casts.

    Torsten Robitzki schrieb:

    - Was sollen regions sein und warum funktioniert ein einfaches Beispiel nicht ohne?

    Durch orthogonale Regionen können in einem Zustand mehrere Unterzustände gleichzeitig (parallel) aktiv sein. Normalerweise hast Du in einer State Machine eine "entweder oder"-Beziehung zwischen Zuständen. Durch Regionen kann man eine "und"-Beziehung modellieren.
    Ein einfaches Beispiel funktioniert natürlich auch ohne. Hier ist die API noch sehr geradlinig und man muss hier die Regionen immer manuell anlegen. Priorität hatte hier erst einmal vollständige Funktionalität.
    Der Komfort soll aber auch nicht leiden:
    Es lässt sich natürlich erreichen, dass in einem Composite State automatisch immer eine "default"-Region vorhanden ist und dass sich ein Einfügen direkt in einen Composite State erstmal direkt auf die "default"-Region bezieht. Ich nehme das auf.

    Torsten Robitzki schrieb:

    - return ist KEINE FUNKTION! 😉

    Das mit dem Klammern ist eine alte Angewohnheit, die ich mir aus meinem ersten C-Buch abgeschaut hatte (von Andre Willms, glaube ich) und das ist dann über die Jahre so geblieben.
    Und die C++-Casts sind auch keine Funktionen, sondern Operatoren und da braucht man auch Klammern. 🤡

    Torsten Robitzki schrieb:

    also wenn ich mir schon die Mühe machen würde, für Zustandsautomaten eine Library zu schreiben, dann:
    - Muss sie das Erstellen eines Automatens auch _deutlich_ vereinfachen.
    - Muss der Automat also solches sehr gut lesbar sein, da meiner Meinung nach, genau dass das Problem von Automaten ist: Sie werden schnell unübersichtlich.

    Ich stimme Dir zu, dass das Definieren des Automaten möglichst elegant und kompakt sein sollte. Da können wir bestimmt auch noch Einiges an "Convenience-Schnittstellen" anbieten. Allerdings war das erste Hauptziel, die vollen Fähigkeiten einer UML State Machine abbilden zu können. Wenn das technisch alles funktioniert, können wir in diesem Bereich an der API noch viel machen.
    Das Definieren des State Machine im Code soll in Zukunft auch noch in den Hintergrund rücken, wenn wir den Rumpf-Code aus einem Modell generieren. Aber das will natürlich nicht jeder so machen und dann sollte eine elegante manuelle Definition möglich sein.
    Aber es kann auch nicht das Ziel sein, dass triviale Beispiele trivial zu implementieren sind und komplexere State Machines dann dramatisch schwieriger in der Umsetzung werden.
    Ich habe lieber ein wenig mehr Aufwand mit einfacheren Konstrukten, wenn ich dafür mit komplexen Konstrukten immer noch sicher umgehen kann.
    Dein Beispiel Pseudo-Code ist natürlich schön kompakt. Aber er deckt jetzt nur einen Corner-Case ab, der nur ein Bruchteil der Features einer UML State Machine nutzt.
    Und das yasmine-Beispiel könnte man auch noch deutlich eindampfen. Das finde ich aber aus didaktischer Sicht ungünstig. Das Beispiel soll zeigen, wie die Konzepte funktionieren und nicht wie man den Code auf möglichst wenige Zeilen presst.

    0

  • Die Namenskonflikte zwischen Klassen, Interfaces und Variablen kann man ganz einfach lösen.

    class Printer;
class IPrinter; // Interface
Printer printer;

    Das ist praktisch und zumindest in der Windows Welt sehr üblich (COM, .NET Framework, Quasi-Standard bei C#, generell viel Code von MS).
    😉

    0
  • T

    hustbaer schrieb:

    Die Namenskonflikte zwischen Klassen, Interfaces und Variablen kann man ganz einfach lösen.

    class Printer;
class IPrinter; // Interface
Printer printer;

    Naja, die "übliche" Lösung dafür ist, das Objekt nach seiner Rolle, nicht nach seinem Typen zu benennen. Du nennst ja einen int auch nicht Int, oder?

    im Beispiel oben wäre dass:

    void check_consumable_levels(const printer& to_be_checked);

    Wenn die Rolle bereits so stark über den Typen definiert ist, dann spricht doch auch überhaupt nix dagegen das Objekt einfach p zu nennen. Oder was würde p_printer in der Situation an zusätzlichen Informationen liefern. Was gibt mir t_ und p_ an zusätzlichen Informationen, die es Wert sind, meinen Lesefluss zu unterbrechen. t_ ist ein Type! Echt? Wow! 😉 Was sollte printer den anderes sein, als ein Typ?

    Am besten noch so etwas: 😉

    /**
 * @param the_printer the printer
 */
void check_consumable_levels(const printer& the_printer);
    0

  • Torsten Robitzki schrieb:

    hustbaer schrieb:

    Die Namenskonflikte zwischen Klassen, Interfaces und Variablen kann man ganz einfach lösen.

    class Printer;
class IPrinter; // Interface
Printer printer;

    Naja, die "übliche" Lösung dafür ist, das Objekt nach seiner Rolle, nicht nach seinem Typen zu benennen. Du nennst ja einen int auch nicht Int, oder?

    im Beispiel oben wäre dass:

    void check_consumable_levels(const printer& to_be_checked);

    Bilderbuchbeispiel => mMn. uninteressant.
    Ja, man sollte Variablen sinnvoll benennen, und sinnvoll ist nicht immer der Typname.
    Allerdings oft halt ... doch. Und dann kollidiert es. Und dann ist unterschiedliche Benamsung praktisch.
    Ist jetzt eigentlich keine Rocket-Science.

    Beispiel:

    void PrintDocument(Document const& document, Rasterizer const& rasterizer, Printer const& printer);

    Was soll man hier umbenennen?
    Meinst du dass "toPrint" statt "document" besser wäre? Bei einer Funktion die ... naja, "print document" heisst? Und was mit den anderen beiden Parametern?

    Torsten Robitzki schrieb:

    Wenn die Rolle bereits so stark über den Typen definiert ist, dann spricht doch auch überhaupt nix dagegen das Objekt einfach p zu nennen.

    Doch. Nämlich dass man, wenn es sich nicht gerade um Parameter handelt, sondern z.B. um lokale Variablen, auto statt des Typs schreibt.
    Dann hast du nur noch "p". Nicht so toll.
    Und ... selbst wenn da wirklich Printer p; steht... und nur 2-3 Zeilen bis zur letzten Verwendung von "p" dazwischen sind... ist es vollkommen unnötige Gehirnakrobatik die Zeile suchen zu müssen wo dann der Typ zu finden ist. Und selbst wenn es nur 1/2 Gehirnzelle beschäftigt, ist das 1/2 Gehirnzelle die mir weniger zur Verfügung steht sinnvolle Dinge abzuchecken bzw. im Gedächtnis zu behalten.

    0

  • Torsten Robitzki schrieb:

    Was gibt mir t_ und p_ an zusätzlichen Informationen, die es Wert sind, meinen Lesefluss zu unterbrechen. t_ ist ein Type! Echt? Wow! 😉 Was sollte printer den anderes sein, als ein Typ?

    OK.

    ... printer() ...

    Typ? Funktion? Variable (Funktor)?
    Doof, nen?

    0
  • A

    Diese Snake-Notation macht die Sache leider nicht leichter. CamelCase ist da schon flexibler, und dann kann der Parameter halt schon print(Printer printer) heißen.

    Bei Snake muss man sich dagegen "Sonderzeichen" bedienen: print(printer printer_)
    Sieht für den Implementierer nicht so toll aus, aber es gibt keinen Konflikt und der User der Funktion muss sich nicht mit unsinnigen Namen anfreunden.

    class Printer;
class IPrinter; // Interface
Printer printer;

    Obiges kenne ich auch so von Java bzw. OSGI-/Eclipse-RPC-Notation. Ist natürlich schön.

    Das würde ich bei Snake anders lösen:

    // Das Interface, der Interface-Name sollte "schön" sein!
class printer;

// Spezielle Implementierung:
class matrix_printer : public printer;
// wenn einem nichts besseres einfällt:
class printer_impl : public printer;

    Da man bei gegen-Interfaces-Programmierung immer und überall auf den Interface-Name trifft, sollte dieser einen schöneren und kürzeren Namen als die implementierende Klasse haben. Denn letztere kommt ja nur beim Instanzieren und somit seltener im Quelltext vor.

    0
  • T

    hustbaer schrieb:

    Beispiel:

    void PrintDocument(Document const& document, Rasterizer const& rasterizer, Printer const& printer);

    Was soll man hier umbenennen?

    Vorschlag:

    void print(Document const& input, Rasterizer const& rules /* or raster */, Printer const& output);

    Wenn ich viel mit Libraries arbeite, die CamelCase verwenden, dann würde ich auch CamelCase verwenden. Wenn ich aber, wie der OP, eine kleine Support-Library schreibe, dann würde ich darauf achten, dass bei gemeinsamer Nutzung mit Elementen aus der Standard-Library, ein ruhiges Gesamtbild entsteht.

    mfg Torsten

    0
Anmelden zum Antworten