Swift Einschätzung

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

  • Dass der Code nicht kompiliert, ist richtig.

    Und nein, du darfst nicht jede Nachricht schicken. Du darfst solche schicken, die deklariert sind. Statik/Dynamik ist ein Begriffspaar, welches sich auf den Zeitpunkt der Evaluierung bezieht. Information-Hiding hat damit erst einmal nichts zu tun.

    Was das Ganze mit Type-Inference zu tun hat, verstehe ich immer noch nicht. Da wird überhaupt nichts geschlossen. Es wird der Typ des Rückgabewertes gelesen und es wird der Typ des Zuweisungszieles gelesen.
    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"?
  • macmoonshine schrieb:


    Das dahinterstehende Paradigma nennt man Datenkapselung.


    ?(

    Amin Negm-Awad schrieb:


    Information-Hiding hat damit erst einmal nichts zu tun.


    Danke.

    Amin Negm-Awad schrieb:


    Und nein, du darfst nicht jede Nachricht schicken. Du darfst solche schicken, die deklariert sind.


    Ist ja:

    Quellcode

    1. SEL selector = @selector(currentPoint);
    2. [[values objectAtIndex:0] performSelector:selector];


    kompiliert und funktioniert sogar.

    Apple meint dazu: “Although identically named class methods and instance methods are represented by the same selector, they can have different argument and return types.”

    Amin Negm-Awad schrieb:

    Was das Ganze mit Type-Inference zu tun hat, verstehe ich immer noch nicht. Da wird überhaupt nichts geschlossen. Es wird der Typ des Rückgabewertes gelesen und es wird der Typ des Zuweisungszieles gelesen.


    Ok, kommen wir etwas von der Typinterferenz runter, sonst kommen wir nie auf den Punkt.

    Der Compiler nimmt einen (falschen) Rückgabewert der Methode an und wählt den falschen Methodenaufruf. Je nach Typ von [values objectAtIndex:0] müsste der Compiler einen Aufruf von objc_msgSend oder objc_msgSend_stret erzeugen, wenn er den Typ kennt klappt das auch:

    Apple schrieb:


    Therefore, except for messages sent to statically typed receivers, dynamic binding requires all implementations of identically named methods to have the same return type and the same argument types.
    (Statically typed receivers are an exception to this rule, since the compiler can learn about the method implementation from the class type.)


    Ich will mich jetzt nicht daran aufhängen wer hier im Forum das als Typinterferenz zählt, der Punkt ist, dass der Compiler den Typ des Objekts bestimmen können muss, sonst gehen Dinge schief. Was hier verletzt wird ist “dynamic binding requires all implementations of identically named methods to have the same return type and the same argument types”. Das passiert aber schnell, zum Beispiel bei length.
  • SteveJ schrieb:

    macmoonshine schrieb:


    Das dahinterstehende Paradigma nennt man Datenkapselung.


    ?(

    Amin Negm-Awad schrieb:


    Information-Hiding hat damit erst einmal nichts zu tun.


    Danke.

    Das sehe ich nach wie vor anders: Du verstößt gegen den Vertrag (die Schnittstelle) der Klasse und nutzt ein undokumentiertes Feature. Dann sagst Du bätsch, das funktioniert nicht. Und das wird auch nicht dadurch besser, dass Du einen Selektor verwendest.

    Aber abgesehen davon: Das ist eine „Schwachstelle“ in Objective-C, die der Compiler nicht automatisiert beheben kann und es deswegen auch nicht tut. Der Compiler kann weder den Typ an dieser Stelle zuverlässig wissen noch raten. Er verlässt sich ganz auf die Informationen, die ihm der Programmierer zur Verfügung stellt.

    Dein Beispiel hat überhaupt aber nichts mit Type-Inference zu tun. Das ist eine Eigenschaft einer Programmiersprache, die der Sprachentwickler als „Feature“ für den Programmierer bereitstellt.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:


    Aber abgesehen davon: Das ist eine „Schwachstelle“ in Objective-C, die der Compiler nicht automatisiert beheben kann und es deswegen auch nicht tut. Der Compiler kann weder den Typ an dieser Stelle zuverlässig wissen noch raten. Er verlässt sich ganz auf die Informationen, die ihm der Programmierer zur Verfügung stellt.


    Du findest also

    Quellcode

    1. NSArray *objects = @[@"Hello", @"world"];
    2. for (id object in objects) {
    3. NSLog(@"length(\"%@\") = %lu", object, [object length]);
    4. }


    unzulässig? Oder

    Quellcode

    1. NSStatusBar *statusBar = [NSStatusBar systemStatusBar];
    2. NSStatusItem *statusItem = [statusBar statusItemWithLength:42.0];
    3. NSLog(@"length(\"%@\") = %f", statusItem, [statusItem length]);
    4. NSArray *objects = @[@"Hello", @"world", statusItem];
    5. for (id object in objects) {
    6. NSLog(@"length(\"%@\") = %lu", object, [object length]);
    7. }


    ?

    Oder, wenn es eine Schwachstelle im Typsystem von Objective-C ist, warum ist sie weniger schlimm als die Typinterferenz in Swift?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von SteveJ ()

  • Was hat die Verwendung von id mit Deinem ersten Beispiel zu tun? Ich finde die Verwendung nicht-deklarierter Methoden unzulässig.

    SteveJ schrieb:

    Oder, wenn es eine Schwachstelle im Typsystem von Objective-C ist, warum ist sie weniger schlimm als die Typinterferenz in Swift?

    Mit „Schwachstelle“* meinte ich, dass es in jeder Programmiersprache Stellen gibt, die der DAP geschickt für seine Zwecke ausnutzen kann. ;) Oder andersherum: Hier ist die Erfahrung des Programmierers gefordert, um diese Klippe zu umschiffen. In Objective-C wird das in der Regel durch aussagekräftige Namen erreicht.

    Im Gegensatz dazu hat Apple die Type-Inference in Swift absichtlich eingebaut, und die Planung und Umsetzung dieses Features hat bestimmt einiges an Zeit gekostet. Das Ergebnis ist jedoch prinzipbedingt dürftig.


    * Beachte die Anführungszeichen
    „Meine Komplikation hatte eine Komplikation.“