Benennung von "Accessors"

[Nexus]

alternato schrieb:

Wenn du an unterschiedlichen Möglichkeiten interessiert bist, dann noch meine:

// [Code-Auszug]
    class Widget {
    public:
        const Size& size() const { return size_; }
              Size& size()       { return size_; }
    private:
        Size size_;
    };

Und wo genau ist hier der Vorteil gegenüber öffentlichen Memberfunktionen?

• Bei veränderbaren Objekten gibst du eine Non-Const-Referenz auf die Variable zurück. Damit hat man den gleichen Zugriff wie auf die Variable selbst.
• Bei konstanten Objekten gibst du eine Const-Referenz oder Kopie zurück. Dadurch kann man die Variable zwar nicht verändern, aber genau das Gleiche trifft auf eine öffentliche Membervariable zu.

Der Unterschied zu public -Variablen sind also lediglich die Klammern beim Aufruf und der zusätzliche Code, was ich nicht unbedingt als Vorteil werten würde.

[Gast]

Hey, danke Nexus für's rauskramen, leider wurde der Thread irgendwie erst interessant mit dem letzten Beitrag, weil sich die Diskussion aus irgendwelchen Gründen vorher eher darum dreht, ob man denn überhaupt accessor-Methoden einsetzen sollte... Der andere Artikel war interessant zu lesen.

[Gast]

Dravere schrieb:

Implementierungen für Properties unter C++ gibt es im Netz schon zahlreiche. Allerdings kann es schnell zu gewissen Unschönheiten und sogar Problemen kommen. C++ hat diese Möglichkeit einfach nicht und sich diese Möglichkeit irgendwie hinzubiegen, halte ich für verkehrt.

Also ohne eingehende Begründung (von der ich fest ausgehe, dass du sie besitzt, nur nicht so weit ausholen wolltest) finde ich die Argumentation "C++" hätte etwas nicht eingabaut -> versuch es nicht trotzdem, wenig überzeugend

[alternato]

Nexus schrieb:

Der Unterschied zu public -Variablen sind also lediglich die Klammern beim Aufruf und der zusätzliche Code, was ich nicht unbedingt als Vorteil werten würde.

Es hat einige zusätzliche Vorteile gegenüber public -Variablen:

• Du kannst die Size irgendwo speichern. In einem std::vector , in einer union , in einem pImpl , usw., ohne dass der Aufrufer davon wissen muss.
• Du hast die Möglichkeit, nicht direkt eine Referenz sondern einen Acessor, der sich so verhält wie eine Size, zurückzugeben. Im Normalfall ist das allerdings nicht nötig.
• Du kannst den Zugriff loggen.
• Einheitlichkeit. Ein öffentlich unveränderlicher Member kann nicht als öffentliche Variable definiert werden, sondern muss wie von der STL von vector::size() als Funktion zur Verfügung stehen. Einmal mit, einmal ohne Klammern - immer mit sehe ich da als Vorteil.

Nexus schrieb:

Und wo genau ist hier der Vorteil gegenüber öffentlichen Memberfunktionen?

• Einheitlichkeit. Ob ein Member unveränderlich ist wie ein vector::size() oder eben doch veränderlich, der Zugriff bleibt gleich.
• Für manche Leute subjektiv schönerer Code ( a.foo() += 5; ).
• Objektiv kürzerer Code.

Muss dich natürlich nicht überzeugen, Boost und mein Lieblingstoolkit verwenden auch die get_prop / set_prop -Variante, das zwingt mich dann doch zu solchen Eigenschaftsfunktionen in allen damit verbundenen Klassen. Ich bin mit meinem Geschmack scheinbar in der Unterzahl.

[Nexus]

C++ hat ja einiges nicht eingebaut. Aber wir haben Templates, um alles nachzubauen
Ich hab teilweise schon echt interessante Ansätze gesehen, z.B. für Reflection, Multiple Dispatch, Lambda-Funktionen, benannte Argumentlisten, ...

Naja, wird wohl etwas OffTopic. Decimad, hast du schon etwas mit dem Accessor herumexperimentiert? Du hast ja gesagt, du sähest die Möglichkeit über Zeiger. Wie würde das konkret aussehen, Funktionalität zu implementieren? Auch über Callables ( std::tr1::function )?

[Gast]

Ruhig Blut junger Padawan
Also in der simpelsten Form würde ich auf die generalisierten Funktionszeiger ala tr1::function gerne erstmal verzichten, da es sich ja erstmal nicht um dynamische Beziehungen handelt, sondern um zur Compile-Zeit festgelegte (von denen man einige in die Laufzeit rüberschleppen muss, weil C++ eben diese Funktionalität nicht eingebaut hat). Man könnte sich natürlich in Form einer weiteren Generalisierung über Verkettungen Gedanken machen, um beispielsweise dynamische Restriktionen der Properties zu implementieren...

[Nexus]

alternato schrieb:

Du kannst die Size irgendwo speichern. In einem std::vector , in einer union , in einem pImpl , usw., ohne dass der Aufrufer davon wissen muss.

Okay, das stimmt.

Du hast die Möglichkeit, nicht direkt eine Referenz sondern einen Acessor, der sich so verhält wie eine Size, zurückzugeben.

Womit wir wieder beim Property wären...

alternato schrieb:

Du kannst den Zugriff loggen.

Aber nur beschränkt. Du kannst nur aufzeichnen, wann die Referenz zurückgegeben wurde, und nicht jede einzelne Veränderung. Du siehst auch nicht, welche Art von Veränderung stattfindet. Das ist ein Nachteil gegenüber SetPosition(absolutePos) und Move(offset) , weil du = und += nicht unterscheiden kannst.

Du kannst aber in der Dokumentation schreiben, dass die Referenz nicht weiterverwendet werden soll, sodass du zumindest den Zeitpunkt kennst. Auch wenn du damit ein paar sinnvolle Fälle einschränkst.

alternato schrieb:

Einheitlichkeit. Ob ein Member unveränderlich ist wie ein vector::size() oder eben doch veränderlich, der Zugriff bleibt gleich.

Was aber auf GetSize() ebenso zutrifft.

alternato schrieb:

Objektiv kürzerer Code.

Das kommt erst bei komplexeren Ausdrücken zum Tragen, wie bei

obj.SetSize(5 * obj.GetSize());
// vs
obj.Size() *= 5;

Dafür nimmst du eine geringere Kontrollmöglichkeit in Kauf (siehe oben). Falls dieser spezifische Fall oft vorkommt, könnte man sich auch sowas überlegen:

obj.Scale(5);

alternato schrieb:

Muss dich natürlich nicht überzeugen [...]. Ich bin mit meinem Geschmack scheinbar in der Unterzahl.

Ich bin nur bisher meist mit konventionellen Get/Set-Methoden zufrieden gewesen. Ab und zu habe ich auch Strukturen mit nur öffentlichen Variablen.

Aber wenn, dann denke ich am ehesten sowas wie den Accessor aus diesem Thread. Diese Alternative könnte durchaus in manchen Fällen Potenzial haben. Und zufälligerweise stehe ich auch gleich vor einem ähnlichen Problem (einer Klasse mit sehr vielen Get/Set-Funktionen).

[Gast]

Nach diesem Motto hatte ich mir das vorgestellt: (Man beachte die nicht so tolle Konstruktion, this vor dem Betreten des Konstruktors zu verwenden...)

template< typename DataType, typename Class, void (Class::*Setter)( const DataType& ), DataType (Class::*Getter)() const >
class Accessor
{
public:
	Accessor( Class* p ) : this_(p) {}

	Accessor& operator=( const DataType& data )
	{
		(this_->*Setter)( data );
		return *this;
	}

private:
	Class* this_;
};

class Test {
public:
	Test() : Value( this ) {}

private:
	void setValue( const int& val ) { std::cout << "Setting to " << val; }
	int getValue() const;

public:
	Accessor< int, Test, &Test::setValue, &Test::getValue > Value;
};

int main()
{
	Test myTest;

	myTest.Value = 10;

	return 0;
}

[Dravere]

Decimad schrieb:

Dravere schrieb:

Implementierungen für Properties unter C++ gibt es im Netz schon zahlreiche. Allerdings kann es schnell zu gewissen Unschönheiten und sogar Problemen kommen. C++ hat diese Möglichkeit einfach nicht und sich diese Möglichkeit irgendwie hinzubiegen, halte ich für verkehrt.

Also ohne eingehende Begründung (von der ich fest ausgehe, dass du sie besitzt, nur nicht so weit ausholen wolltest) finde ich die Argumentation "C++" hätte etwas nicht eingabaut -> versuch es nicht trotzdem, wenig überzeugend

Gut, dann bringe ich mal ein einfaches Argument:
Man verwendet Getter und Setter unterandem, damit zusätzlicher Code bei der jeweiligen Aktion durchgeführt werden kann. Auch wenn es nur ein Breakpoint ist oder man die Aktion protokollieren möchte. Wie erreichst du dies mit den nachgebauten Properties? Geht nicht! Es erfordert gleich die Abänderung der Property-Hilfsklasse und betrifft somit alle Properties, statt nur eines einzelnen. Oder dann muss man einen Callback-Mechanismus einbauen, welcher aber recht aufwendig sein kann. std::tr1::function oder boost::function sind unheimlich komplexe Gebilde und kosten auch einiges an Zeit. Wenn man anfängt für so Dinge wie Setter und Getter viel Zeit zu verbraten, nur weil man dadurch 3 Zeichen einsparen kann, dann ist das irgendwie recht fraglich.
Wenn du die Properties in C# ansiehst, dann kannst du dort ganz einfach die Getter und Setter eines jeden Properties an deine Bedürfnisse anpassen, ohne zusätzliche Laufzeit zu verbraten.

Es ist alles eben ein wenig eine Frage des Preis-Leistungsverhältnis. Was bringen einem Properties in C++? Das einzige Argument ist, welches ich bisher gesehen habe, dass man nicht mehr size() schreiben muss sondern size . Es geht also darum zwei Klammern einzusparen. Damit soll angeblich die Lesbarkeit erhöht werden. Dass man auch mit temporären Zwischenvariablen arbeiten kann, wird hingegen oft ignoriert:

int x = pos.get_x();
int y = pos.get_y();
int width = rect.get_width();

int index = y * width + x;

Was soll daran unübersichtlich sein?

Ein anderes bisschen einfacheres Argument:
Wie machst du Properties kopierbar, aber von aussen nicht zuweisbar?

Properties Workarounds in C++ bieten keinerlei relevanten Vorteil. Dafür können sie Nachteile mit sich bringen. Wieso sollte man also eine Technik einsetzen, welche unter dem Strich nichts bringt?

Grüssli

[Nexus]

Decimad schrieb:

Also in der simpelsten Form würde ich auf die generalisierten Funktionszeiger ala tr1::function gerne erstmal verzichten, da es sich ja erstmal nicht um dynamische Beziehungen handelt, sondern um zur Compile-Zeit festgelegte

Genau, deshalb auch noch der Vorschlag "Da Accessor ein Template ist, könntest du unter Umständen sogar (Member-)Funktionszeiger als Template-Parameter fest verdrahten." Scheinbar hast du das auch gerade getan

Mit Metaprogrammierung könnte man wahrscheinlich noch etwas optimieren, sodass z.B. int statt const int& verwendet werden kann.

Decimad schrieb:

Man beachte die nicht so tolle Konstruktion, this vor dem Betreten des Konstruktors zu verwenden...

Ist das ein Problem? Du verwendest ja nur den Zeiger als Verweis. Soweit ich weiss, wird es erst beim tatsächlichen Zugriff auf this problematisch...

[Gast]

Ja, Nexus, ich habe mir schon ein ParameterType-Template geschrieben, dass entsprechend Referenzen oder Per-Value macht, je nachdem wie groß die Typen sind, das könnte man hier natürlich einsetzen, aber hätte nicht der übersichtlichen Darstellung der Idee gedient^^

[Gast]

Dravere, ich kann das alles nachvollziehen, was du schreibst. Allerdings ist meinem Beispiel nicht der Vorteil tragend, dass man sich das () spart, sondern dass man die intuitive Zuweisungs-Operation benutzen kann (zumindest in meinen Augen). Zudem hat man intern immernoch den setter und den getter, sodass man dort alles machen kann, was man auch normalerweise tun kann. Mit den Kosten hast du natürlich recht, mir ist auch ein Dorn im Auge, dass ich den this-Zeiger mitspeichern muss, aber die Kosten sind nicht so hoch wie tr1::function und ähnlich dynamisches (das wollte ich ja gezielt vermeiden, wie ich auch schon schrieb).
Ich hasse solche Konflikte, ganz ehrlich

[Dravere]

Decimad schrieb:

Allerdings ist meinem Beispiel nicht der Vorteil tragend, dass man sich das () spart, sondern dass man die intuitive Zuweisungs-Operation benutzen kann (zumindest in meinen Augen).

Es geht also darum?

text.x = 20;
text.set_x(20);

Du willst wirklich diesen riesigen Aufwand betreiben wegen sowas? Dir alle Nachteile (gibt noch mehr als bisher genannt) einkaufen, weil du es ein bisschen intuitiver findest? Setter und Getter sind äusserst üblich in Programmiersprachen. Daran gewöhnst du dich sehr schnell.

Decimad schrieb:

Ich hasse solche Konflikte, ganz ehrlich

Ich sehe keinen Konflikt. Die Kosten sind im Verhältnis zum Nutzen so überdimensional, dass die einzig logische Entscheidung gegen Property Workarounds in C++ sein muss.
Mag zwar eine interessante akademische Überlegung sein und vielleicht Spass machen, sowas mal auszuprobieren - was ich auch schon gemacht habe, aber für den praktischen Einsatz ist es einfach untauglich.

Grüssli

[Nexus]

Dravere schrieb:

Es erfordert gleich die Abänderung der Property-Hilfsklasse und betrifft somit alle Properties, statt nur eines einzelnen. Oder dann muss man einen Callback-Mechanismus einbauen, welcher aber recht aufwendig sein kann. std::tr1::function oder boost::function sind unheimlich komplexe Gebilde und kosten auch einiges an Zeit.

Darum auch die Hardwire-Lösung über Templateparameter. Accessor muss dazu nicht verändert werden, da es generisch ist.

Dravere schrieb:

Dass man auch mit temporären Zwischenvariablen arbeiten kann, wird hingegen oft ignoriert:

// [leicht abgeändert]
int x = pos.get_x();
int y = pos.get_y();
int width = rect.get_width();

pos.set_x(y * width + x); // [Setter eingebaut]

Und dass das viel mehr Code als

pos.x = pos.y * pos.width + pos.x; // oder auch
pos.x() = pos.y() * pos.width() + pos.x();

braucht, wird scheinbar von dir ignoriert.

Dravere schrieb:

Was soll daran unübersichtlich sein?

Es ist nicht unübersichtlich, aber es braucht verdammt viel Code, um fast nichts zu erreichen. Bei grösseren Objekten kommt die Kopie dazu. Es sei denn, du speicherst etwas als Const-Referenz (falls auch eine solche zurückgegeben wird), womit aber auch viele Leute ein Problem haben.

Dravere schrieb:

Ein anderes bisschen einfacheres Argument:
Wie machst du Properties kopierbar, aber von aussen nicht zuweisbar?

Das ist ein guter Punkt, hier müsste man sich was überlegen. Eine Einschränkung wäre vielleicht, dass man trotzdem den operator() aufruft, um auch keine Konflikte mit impliziten Konvertierungen etc. zu bekommen.

Dravere schrieb:

Properties Workarounds in C++ bieten keinerlei relevanten Vorteil. Dafür können sie Nachteile mit sich bringen. Wieso sollte man also eine Technik einsetzen, welche unter dem Strich nichts bringt?

Die Prämisse stimmt schon nicht. Mit Properties kann man eine einfachere und intuitivere Syntax haben.

Natürlich sind sie nicht ganz so toll wie in C#, und es gibt einige Einschränkungen. Für den Alltagsgebrauch würde ich auch klassische Setter/Getter empfehlen. Aber nur weil man ein Sprachkonzept an eine andere Sprache anlehnt, schrillen bei dir die Alarmglocken und du musst jeden Versuch schon kategorisch schlecht finden.

Die Idee von Properties ist interessant. Ich sage nicht, man soll sie jetzt immer einsetzen. Aber man kann ja mal ein wenig herumexperimentieren, was sie alles so können, ohne gleich in die böse Sprachkonzept-Übernehmer-Schublade gesteckt zu werden. Gut möglich, dass sie sich nicht bewähren, aber dann wars ein lustiges Experiment.

[Gast]

Naja, ich programmiere jetzt schon etwas länger C++ und muss halt sagen, dass ich mich noch nicht daran gewöhnt habe. Das Problem mit dem Menschen ist doch, wenn er etwas nicht mag, aber nach dem Motto "da gewöhnst du dich schon dran" trotzdem in das Muster gepresst wird, fühlt er sich nicht mehr wohl. Ich mag vieles an C++, dieser Teil hat mich schon immer genervt, deshalb versuche ich da nun eine Lösung zu finden.
Ich für meinen Teil werde auf jeden Fall mal meine Widget-Bibliothek nach dem Muster neu aufsetzen (und dem des anderen Threads) und schauen, was bei rauskommt. Schließlich wird das Zurückrudern ja relativ leicht gemacht, weil die getter und setter noch da sind.

[Nexus]

Ich würde vielleicht schon zuerst etwas testen, bevor du deine ganze Bibliothek umschreibst.

Es gibt nämlich noch ein paar ungelöste Probleme. Zum einen der von Dravere angesprochene Punkt mit dem Kopieren, zum anderen musst du für die Getter Konvertierungsoperatoren anbieten, welche halt nicht in jedem Kontext aufgerufen werden. Und zum Laufzeit-Overhead... Hängt halt wieder davon ab, wie zeitkritisch alles ist.

Nach allen Anpassungen sind die Unterschiede zu Settern/Gettern wahrscheinlich zu klein, als dass Properties sich wirklich äusserst lohnen würden. Kommt halt drauf an, wie wichtig die Syntax ist...

[Gast]

Also im Vergleich zu den Blit-Operationen, Baum-Updates etc. ist der Overhead von den Accessors in der äußersten Hülle des ganzen wahrscheinlich vernachlässigbar. Wie gesagt, Zurückrudern ist dann ja nur eine Fleißaufgabe

[Dravere]

Nexus schrieb:

Darum auch die Hardwire-Lösung über Templateparameter. Accessor muss dazu nicht verändert werden, da es generisch ist.

Du vergisst hier aber, dass man keine Kontrolle über Zeitpunkte hat. Wird die Funktion jetzt davor oder danach aufgerufen? Kann ich die Zuweisung verhindern, wenn ein falscher Wert übergeben wird? Am Ende hast du dann 4 Funktionen als Templateparameter? Sieht ja sehr nett aus

Nexus schrieb:

Dravere schrieb:

Dass man auch mit temporären Zwischenvariablen arbeiten kann, wird hingegen oft ignoriert:

// [leicht abgeändert]
int x = pos.get_x();
int y = pos.get_y();
int width = rect.get_width();

pos.set_x(y * width + x); // [Setter eingebaut]

Und dass das viel mehr Code als

pos.x = pos.y * pos.width + pos.x; // oder auch
pos.x() = pos.y() * pos.width() + pos.x();

braucht, wird scheinbar von dir ignoriert.

WOW! Welch unheimlicher zusätzliche Aufwand! Seit wann ist Schreibfaulheit ein guter Ansatz in der Programmierung? Komm, wir führen wieder Abkürzungen für alles ein, damit wir nicht so viel schreiben müssen!

Nexus schrieb:

Es ist nicht unübersichtlich, aber es braucht verdammt viel Code, um fast nichts zu erreichen.

Bitte nicht übertreiben. Das hat man innert Sekunden hingetippt.

Nexus schrieb:

Bei grösseren Objekten kommt die Kopie dazu. Es sei denn, du speicherst etwas als Const-Referenz (falls auch eine solche zurückgegeben wird), womit aber auch viele Leute ein Problem haben.

Die Kopie hast du auch so. Der Kompiler optimiert dies weg.

Nexus schrieb:

Das ist ein guter Punkt, hier müsste man sich was überlegen. Eine Einschränkung wäre vielleicht, dass man trotzdem den operator() aufruft, um auch keine Konflikte mit impliziten Konvertierungen etc. zu bekommen.

Implizite Konvertierungen kannst du mit explicit gut verhindern. Aber das mit dem operator() musst du mir erklären. Willst du dann dies einbauen?

text.x(10);

Nexus schrieb:

Die Prämisse stimmt schon nicht. Mit Properties kann man eine einfachere und intuitivere Syntax haben.

Gut, es gibt einen minimalen Vorteil. Du willst doch nicht sagen, dass dies so wahnsinnig viel einfacher und intuitiver ist? Man ist sich an Setter schon längsten gewohnt in C++ und nicht nur dort.

Nexus schrieb:

Aber nur weil man ein Sprachkonzept an eine andere Sprache anlehnt, schrillen bei dir die Alarmglocken und du musst jeden Versuch schon kategorisch schlecht finden.

Nein, ich habe damit herumexperimentiert und habe so viele Nachteile gefunden, dass es einfach keine gute Idee ist. Ich fand die Properties aus C# nämlich ganz toll und wollte sie mir auch in C++ nachbauen. Man stösst auf so viele Probleme, sobald man die Dinger einsetzen möchte, dass ist unglaublich. Am Ende setzt man "einfache" Eigenschaften über Properties um und den Rest wieder über Setter und Getter. Wenn man dann was verändern muss, muss man plötzlich Properties entfernen und durch Setter und Getter ersetzen, da es nicht anders geht. Das wird zu einem unglaublichen Mischmasch, welcher auch schwer zu warten ist. Man bricht in so einem Fall dann auch die Schnittstelle, was zu einem Refactoring in der Bibliothek führt und dazu noch einer Inkompatibilität in den Versionen. Die Benutzer der Bibliothek werden dich lieben! Und von Konsistenz ist dann auch keine Spur mehr vorhanden.

Nexus schrieb:

Die Idee von Properties ist interessant. Ich sage nicht, man soll sie jetzt immer einsetzen. Aber man kann ja mal ein wenig herumexperimentieren, was sie alles so können, ohne gleich in die böse Sprachkonzept-Übernehmer-Schublade gesteckt zu werden. Gut möglich, dass sie sich nicht bewähren, aber dann wars ein lustiges Experiment.

Gegen das Herumexperimentieren haben ich ja nichts. Nur habe ich diese Experimente bereits hinter mir

Um euch mal zusätzliche Probleme zu geben:
Damit man Konsistenz erreichen kann, sollte man auch ausschliesslich Getter-Properties und/oder Setter-Properties erstellen. Also Properties welche man nur abrufen, bzw. beschreiben, kann. Und in der eigentlichen Klassen, muss man dann trotzdem noch vollen Zugriff haben. In C# kein Ding, in C++ eine richtige Herausforderung, welche noch mehr Probleme offenbart.

Grüssli

[Dravere]

Mist, noch einen Code vergessen, welcher euch noch mehr Kopfzerbrechen geben soll:

#include <iostream>

template< typename DataType, typename Class, void (Class::*Setter)( const DataType& ), DataType (Class::*Getter)() const >
class Accessor
{
public:
  Accessor( Class* p ) : this_(p) {}

  Accessor& operator=( const DataType& data )
  {
    (this_->*Setter)( data );
    return *this;
  }

  operator DataType() const
  {
    return (this_->*Getter)();
  }

private:
  Class* this_;
};

class Test
{
private:
  char const* m_name;

public:
  Test(char const* name) : Value(this), m_name(name) {}

private:
  void setValue( const int& val ) { std::cout << m_name << std::endl; }
  int getValue() const { std::cout << m_name << std::endl; return 0; }

public:
  Accessor< int, Test, &Test::setValue, &Test::getValue > Value;
};

int main()
{
  Test test01("A");
  Test test02("B");

  test01.Value = test02.Value;

  std::cout << test01.Value << std::endl;
  std::cin.get();
}

Viel Glück beim Lösen von diesem Problem
Die Klasse Test soll bitte kopierbar bleiben!

Grüssli

[Gast]

So, jetzt habe ich wirklich Zeit mich damit zu beschäftigen und setze mir erstmal einen Kaffee auf. Ruhig Blut meine jungen Padawane, wir führen doch hier eine sachliche Diskussion und ich für meinen Teil beanspruche für mich gar kein Recht, ich bin nur noch nicht überzeugt, und das ist nicht euer Fehler, sondern meine mangelnde Durchdringung des ganzen

Ein anderes bisschen einfacheres Argument:
Wie machst du Properties kopierbar, aber von aussen nicht zuweisbar?

Warum sollte ich Properties kopierbar machen? Eigentlich hätte ich jetzt sogar vorgehabt, den Kopierkonstruktor privat zu machen etc..
Ich habe diese syntaktischen Nachteile noch nicht so durchdrungen. Könnt ihr mir bitte Benutzungsfälle aufzeigen, bei denen das zu Tage tritt? Dann kann ich da zielgerichteter drüber nachdenken.

Viele Grüße,
Deci

Edit: Voranstehendes Beispiel hatte ich da noch nicht gelesen, im Moment dabei!