CGPoint und Property erweitern

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Nee, kannste nicht. Extensions sind unter Swift und waren unter Objective–C dazu gedacht, Funktionalität hinzuzufügen.
    Eigenschaften hinzufügen ist nicht Teil des Plans.

    Klar kannste. Ein bisschen in Objective–C mit malloc() und Pointern herumspielen, und Du erzeugst Dir den ganzen Kram dynamisch zur Laufzeit.
    Solltest Du aber sein lassen.

    Bau Dir eine eigene Struktur (Klasse wäre sinnlos, ein CGPoint ist aus Gründen eine Struktur) 'SelectablePoint' und häng die Member und Logik entsprechend rein.

    Genau wie inflationäres Ableiten von Klassen ein Designproblem ist, ist inflationäres Erweitern von Datenstrukturen ein Designproblem.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    Nee, kannste nicht. Extensions sind unter Swift und waren unter Objective–C dazu gedacht, Funktionalität hinzuzufügen.
    Eigenschaften hinzufügen ist nicht Teil des Plans.

    Klar kannste. Ein bisschen in Objective–C mit malloc() und Pointern herumspielen, und Du erzeugst Dir den ganzen Kram dynamisch zur Laufzeit.
    Solltest Du aber sein lassen.

    Bau Dir eine eigene Struktur (Klasse wäre sinnlos, ein CGPoint ist aus Gründen eine Struktur) 'SelectablePoint' und häng die Member und Logik entsprechend rein.

    Genau wie inflationäres Ableiten von Klassen ein Designproblem ist, ist inflationäres Erweitern von Datenstrukturen ein Designproblem.
    Danke für den Ansatz, das mit dem Struct klingt vernünftig.

    Danke auch an den Rest für die Antworten!
    Man kann alles schaffen. Man muss es nur wollen ;)
    www.regetskcob.github.io

  • Apple schrieb:

    Extensions can add new computed properties, but they cannot add stored properties, or add property observers to existing properties.
    Das Problem, in Swift wie in Objective-C, liegt darin, dass eine Stored-Property Speicherplatz benötigt. Daher wäre es nötig, bei Erzeugung einer Instanz sämtliche Extensions zu kennen, um deren Gesamtspeicherplatz zu ermitteln.

    In Swift ist das daher unmöglich by Design. In Objective-C wäre es auch nur möglich, wenn sämtliche Bundles vor der Erzeugung der ersten Instanz geladen wären.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Zur Frage:

    Jein

    sizeof() wird zur Compile-Zeit ausgewertet, es sei denn, der Operand ist ein VLA. Dann geht das natürlich nicht und es muss zur Laufzeit bestimmt werden:

    C-Quellcode

    1. int n = 3;
    2. int f[n];
    3. sizeof(f);

    Hier kann das Ergebnis von sizeof() erst zur Laufzeit bestimmt werden.

    Zur Schlussfolgerung:


    Obejctive-C verwendet zur Berechnung der Instanzgröße kein sizeof(). Was würdest du da auch hereinschieben wollen? Vielleicht sizeof(NSString)? Das geht nicht. Darüber hinaus kann man bei der Installierung "Extra-Bytes" als Argument mitgeben. Die Berechnung geschieht also zur Laufzeit.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Zur Frage:

    Jein

    sizeof() wird zur Compile-Zeit ausgewertet, es sei denn, der Operand ist ein VLA. Dann geht das natürlich nicht und es muss zur Laufzeit bestimmt werden:

    C-Quellcode

    1. int n = 3;
    2. int f[n];
    3. sizeof(f);
    Hier kann das Ergebnis von sizeof() erst zur Laufzeit bestimmt werden.

    Zur Schlussfolgerung:


    Obejctive-C verwendet zur Berechnung der Instanzgröße kein sizeof(). Was würdest du da auch hereinschieben wollen? Vielleicht sizeof(NSString)? Das geht nicht. Darüber hinaus kann man bei der Installierung "Extra-Bytes" als Argument mitgeben. Die Berechnung geschieht also zur Laufzeit.
    in dem beispiel würde der compiler ja sehen dass n nur 3 sein kann aber mir ist klar dass es bei VLA nicht möglich ist und bei NSString keinen sinn macht. aber zb bei CGPoint oder kannst du dir sicher sein dass in den untiefen des systemcodes das nirgends verwendet wird?

  • Ich glaube kaum, dass bei der Erzeugung einer Struktur auf dem Stack der Compiler auf sizeof() zurück greift.

    Aber da sich die Frage ohnehin nur bei Objective-C stellt und dies keine Protokolle auf Structs kennt, verstehe ich deinen Gedankengang ohnehin nicht.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Ich glaube kaum, dass bei der Erzeugung einer Struktur auf dem Stack der Compiler auf sizeof() zurück greift.

    Aber da sich die Frage ohnehin nur bei Objective-C stellt und dies keine Protokolle auf Structs kennt, verstehe ich deinen Gedankengang ohnehin nicht.
    für den stack natürlich nicht aber für den heap. und ich rede auch nicht vom compiler sondern von system-code der zb irgendwo "malloc(sizeof(CGPoint) * n)" verwendet.
    Da sizeof() ja in dem fall ein compiletime-operator ist würde das ganz schön in die hose gehen wenn CGPoint zur laufzweit plötzlich durch irgend eine extension mehr speicher benötigen würde als sizeof() zur compilezeit ermittelt hat.
    es müsste also bereits zur compilezeit feststehen welche extensions es gibt (nicht wie du gesagt hast vor der erstellung der ersten instanz) oder sizeof() kein compile-time-operator mehr sein (und jegliche software neu compiliert werden.

    also doch gut dass apple daniels wunsch nicht ermöglicht ;)

  • Ich glaube, jetzt drehst du durch.

    Erst:

    gritsch schrieb:

    ist sizeof() nicht ein compile-time operator?

    es wäre also nur möglich wennn zur compile-zeit bereits alle extensions bekannt wären.
    Dann:

    gritsch schrieb:

    für den stack natürlich nicht aber für den heap. und ich rede auch nicht vom compiler sondern von system-code der zb irgendwo "malloc(sizeof(CGPoint) * n)" verwendet.
    Wenn es zur Compile-Zeit geschehen soll, dann macht es der Compiler. Das Laufzeitsystem existiert zur Übersetzungszeit nicht.

    Aber wie gesagt spielt das ohnehin kein Rolle, weil sich dass hier …

    gritsch schrieb:

    Da sizeof() ja in dem fall ein compiletime-operator ist würde das ganz schön in die hose gehen wenn CGPoint zur laufzweit plötzlich durch irgend eine extension mehr speicher benötigen würde als sizeof() zur compilezeit ermittelt hat.
    … ja nur auf Objective-C beziehen kann und Objective-C keine Protokolle auf Structs kennt.

    Auf Klassen, nur darum kann es gehen, bezogen geht das aber in Objective-C, weil a) kein sizeof() verwendet wird und daher b) das Laufzeit ermittelt und daher c) es kein Problem wäre, wenn alle Protokolle zur Laufzeit bekannt wären. Es ist ein leichtes, die Liste der ivars und Properties auch aus Protokollen zur Laufzeit zu bestimmen. Man könnte auch explizite ivars leicht in Protokolle und Extensions einbauen, halt analog zu Klassen. Aber man müsste eben alle Protokolle (und Extensions) kennen.

    (Bei Protokollen halte ich es übrigens für semantisch falsch, weil ein Protokoll eine API deklariert, während eine Ivar ein Implementierungsdetail ist. Aber bei Extensions wäre es denkbar.)
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    In Objective-C wäre es auch nur möglich, wenn sämtliche Bundles vor der Erzeugung der ersten Instanz geladen wären.
    das hast du geschrieben und das wollte ich widerlegen, denn dies müsste man schon zur compilezeit wissen und nicht erst zur laufzeit wenn die erste instanz erzeugt wird.

    aber nun mach weiter mit deinen fehlinterpretationen anderer geschrieber worte und werd glücklich!

  • Natürlich ist das in Objective-C möglich. Die Größe einer Klasse kann leicht zur Laufzeit bestimmt werden. Dazu gibt es eine Ivar-Liste. Genauso gut kann eine Extension im RTE abgebildet werden und eine solche Ivar-Liste erhalten.

    Es ist bloß vergebliche Liebesmüh, da man dann alle Bundles kennen müsste.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Natürlich ist das in Objective-C möglich. Die Größe einer Klasse kann leicht zur Laufzeit bestimmt werden. Dazu gibt es eine Ivar-Liste. Genauso gut kann eine Extension im RTE abgebildet werden und eine solche Ivar-Liste erhalten.

    Es ist bloß vergebliche Liebesmüh, da man dann alle Bundles kennen müsste.
    wir sprachen von structs und du jetzt plötzlich von klasen.

    komisch aber dass ich deine beiträge überhaupt noch sehe - funktioniert das killfile des forums nicht oder blockiert das nur private nachrichten?