Design-Frage: private-Zugriff bei einer Property-Klasse simulieren

otze

property war doch diese tolle erfindung, die sich wie ein objekt verhält, aber kein objekt sein muss,sondern nur die kapselung irgendeines geters/seters sein konnte, oder?

wenn ich richtig liege, so darf ein property eh nicht an ein objekt gebunden sein, da das property ja auch einen abstrakten wert, wie zb die länge eines vectors darstellen kann:

vector v;
//...
double length=v.length;//abstrakter wert berechnet aus sqrt(x*x+y*y+z*z)
v.length=1;//vector auf die länge eins bringen, wieder eine abstrakte berechnung

daraus schließe ich, dass das objekt hinter der property(falls so eins existiert), innerhalb der Klasse liegen sollte, und das property nur die erscheinung nach aussen repräsentiert.

hier ein beispiel:

class Foo{
    private:
        int internalBar;
        int barGetter(){
            return internalBar;
        }
        void barSetter(int newBar){
            internalBar=newBar;
        }
    public:
        Foo():bar(functor(this,barGetter),functor(this,barSetter)){}
        property<int> bar; 
};

wie gesagt, dieser vorschlag trifft nur zu, wenn meine obere definition richtig ist, ansonsten bitte milde walten lassen

rüdiger

@otze und groovemaster
Die Problematik, die ihr ansprecht wird bei mir dadurch umgangen, dass es neben den Get- und Set-Policys auch noch eine Storage-Policy gibt, die sich um die Verwaltung des Objektes kümmert, so wär es also möglich auch otzes Ansatz zu realisieren.

Ich glaub ich muss das intern noch ein wenig verzahnen, um es praktisch nutzbarer zu machen. Ich werde am Wochenende mal meine Arbeiten vorstellen.

otze

aber wie willst du mithilfe dieser storage policie eine interaktion der einzelnen properties erreichen?

rüdiger

ja, daran arbeite ich noch, das meinte ich mit Verzahnung *g*. Irgend wie brauchen die Getter und Setter ja einen Hinweis auf die instanziierte StoragePolicy. Schade, dass es kein has_function<Klasse,Funktion> gibt

groovemaster

kingruedi schrieb:

Ich glaub ich muss das intern noch ein wenig verzahnen, um es praktisch nutzbarer zu machen. Ich werde am Wochenende mal meine Arbeiten vorstellen.

Da bin ich mal gespannt. Ich arbeite nun schon seit einiger Zeit an einer Property Klasse und hab bisher zwar was für mich brauchbares aber noch nichts zufrieden stellendes hinbekommen.

otze

Schade, dass es kein has_function<Klasse,Funktion> gibt

solange es ein isDerived gibt, ist das kein problem.
property muss einfach von StoragePolicy erben.

//edit hmm wie wollt ihr eigentlich komplexere objekte darstellen?
wollt ihr nur zugriff über den op-> erlauben? der op. ist ja nicht erlaubt(leider).

groovemaster

otze schrieb:

//edit hmm wie wollt ihr eigentlich komplexere objekte darstellen?
wollt ihr nur zugriff über den op-> erlauben? der op. ist ja nicht erlaubt(leider).

Solche Sachen sind imo noch ziemlich komplex. Zumindest hab ich noch keine zufrieden stellende Lösung gefunden. Nur mal so als Beispiel, gegeben sei folgender Typ

struct point
{
    int x;
    int y;
    point(int x_, int y_)
        : x(x_)
        , y(y_)
    {
    }
};

Davon erstellen wir uns nun ein Property

property<point, setter, getter> position;

Sobald wir folgende Sachen machen

position = point(0, 0);
point tmp = position;

ist alles ok, da die getter/setter aufgerufen werden. Was ist aber mit folgendem

position.x = 10;
int tmp = position.y;

?
Das funktioniert erstmal nur, wenn das property von point erbt. Und selbst dann werden keine getter/setter aufgerufen, sondern einfach stur die x/y Member benutzt. Damit sowas richtig funktioniert, müsste point wie folgt aussehen

struct point
{
    property<int, setter_x, getter_x> x;
    property<int, setter_y, getter_y> y;
    point(int x_, int y_)
        : x(x_)
        , y(y_)
    {
    }
};

Natürlich kann man keine bestehenden Datentypen einfach so anpassen. Abhilfe könnten hier Template Typen schaffen. Dann wird aus T=int halt einfach T=propety<int, ...>. Ich denke allerdings, dass auch sowas einige schwer zu lösende Probleme hat. Aber vielleicht weiss king ja schon mehr.

rüdiger

wollt ihr nur zugriff über den op-> erlauben? der op. ist ja nicht erlaubt(leider).

Ich biete den op-> an, der op. funktioniert nur für konstante Methoden bei mir!

Der op-> liefert ein temporäres Objekt zurück, dass intern eine Kopie der StoragePolicy enthält, die einmal via Getter bearbeitet wurde und wenn das Objekt geändert wurde, dann wird es am Ende der Lebenszeit des temp-Objekts via des Setters zurückkopiert.

kingruedi schrieb:

Ich werde am Wochenende mal meine Arbeiten vorstellen.

Warum hast du es nicht veröffentlicht. Ich wäre sehr interessiert mir das ganze mal anzuschauen.

leo aka qsch

habe mir nur kurz die Problemstellung durchgelesen,
vielleicht suchst du Slüsselwort friend

rüdiger

@Moppelkotze
Ein paar Design und andere Probleme haben das verschoben, aber ich werd das noch dieses Jahr fertig stellen.

@leo aka qsch
Nein, dass kann man nämlich mit Template-Parametern nicht benutzen.

ness

Warum eigentlich? (Nervt mich auch)

kingruedi schrieb:

@Moppelkotze
Ein paar Design und andere Probleme haben das verschoben, aber ich werd das noch dieses Jahr fertig stellen.

Cool, freue mich schon drauf .

otze

ness schrieb:

Warum eigentlich? (Nervt mich auch)

weil es jedwede kapselung ad absurdum führen würde