didSet aus der Init Wilkür oder Sinn?

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

  • didSet aus der Init Wilkür oder Sinn?

    in folgendem Code wird didSet für session NICHT ausgeführt

    Quellcode

    1. var session: WCSession? {
    2. didSet {
    3. if let session = session {
    4. session.delegate = self
    5. session.activateSession()
    6. }
    7. }
    8. }
    9. override init() {
    10. super.init()
    11. if WCSession.isSupported() {
    12. session = WCSession.defaultSession()
    13. }
    14. }
    Alles anzeigen


    selber code, nur das der session kram in eine Methode ausgelagert wurde, didSet wird ausgeführt

    Quellcode

    1. var session: WCSession? {
    2. didSet {
    3. if let session = session {
    4. session.delegate = self
    5. session.activateSession()
    6. }
    7. }
    8. }
    9. override init() {
    10. super.init()
    11. setupSession()
    12. }
    13. private func setupSession() {
    14. if WCSession.isSupported() {
    15. session = WCSession.defaultSession()
    16. }
    17. }
    Alles anzeigen
    Frage: Was soll das?
    Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. :saint:
  • weil du so auf die property zugreifst und die ist als Optional deklariert

    alternativ kannst du auch schreiben:

    Quellcode

    1. if let localSession = session {
    2. localSession blah
    3. }

    oder

    Quellcode

    1. if let _ = session {
    2. irgendwelcher code
    3. }
    wenn du session da eig nicht brauchst aber sicherstellen musst das du die session hast

    finde diese if let, guard let und optional kram auch echt anstrengend
    Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. :saint:
  • gritsch schrieb:

    nussratte schrieb:

    dann musst du aber in deiner if wieder session? bzw session! schreiben, das entfällt bei if let, weil es in dem block nich nil sein kann
    warum funktioniert sowas nicht?
    Wenn du es "unschön" haben möchtest, kannst du auch das nehmen

    Quellcode

    1. if (session != nil) // or session != nil // or whatever
    2. {
    3. session!.delegate = self
    4. session!.activateSession()
    5. }
  • matz schrieb:

    gritsch schrieb:

    nussratte schrieb:

    dann musst du aber in deiner if wieder session? bzw session! schreiben, das entfällt bei if let, weil es in dem block nich nil sein kann
    warum funktioniert sowas nicht?
    Wenn du es "unschön" haben möchtest, kannst du auch das nehmen

    Quellcode

    1. if (session != nil) // or session != nil // or whatever
    2. {
    3. session!.delegate = self
    4. session!.activateSession()
    5. }
    und warum muss das sein?
    der compiler sieht ja selbst dass es nicht nil ist wenn es einmal geprüft wurde und dann nicht geändert wird.
    dann lieber eine neue lokale variable erstellen (mit dem gleichen namen auch noch...) oder?
  • gritsch schrieb:

    matz schrieb:

    gritsch schrieb:

    nussratte schrieb:

    dann musst du aber in deiner if wieder session? bzw session! schreiben, das entfällt bei if let, weil es in dem block nich nil sein kann
    warum funktioniert sowas nicht?
    Wenn du es "unschön" haben möchtest, kannst du auch das nehmen

    Quellcode

    1. if (session != nil) // or session != nil // or whatever
    2. {
    3. session!.delegate = self
    4. session!.activateSession()
    5. }
    und warum muss das sein?
    Weil Optionals nun mal so funktionieren.

    gritsch schrieb:

    der compiler sieht ja selbst dass es nicht nil ist wenn es einmal geprüft wurde und dann nicht geändert wird.
    dann lieber eine neue lokale variable erstellen (mit dem gleichen namen auch noch...) oder?
    Kannst ja ein Proposal schreiben, damit die das ändern.
  • matz schrieb:

    Wenn du es "unschön" haben möchtest, kannst du auch das nehmen


    if (session != nil) // or session != nil // or whatever
    {
    session!.delegate = self
    session!.activateSession()
    Das ist aber nicht nur unschön, sondern auch unsicher:
    Wenn session in Zeile 1 nicht nil ist, heisst das nicht automatisch, dass der Wert in Zeile drei noch gleich ist...

    Multithreading ist ja inzwischen harte Realität - ARC verdanken wir wahrscheinlich dem selben Umstand (früher war es sehr viel weniger riskant, auf das eine oder andere "retain" zu verzichten).


    gritsch schrieb:


    der compiler sieht ja selbst dass es nicht nil ist wenn es einmal geprüft wurde und dann nicht geändert wird.
    s.o. - nur weil es keine Änderung im aktuellen Scope gibt, heisst das noch lange nicht, dass sich der Wert nicht verändert.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von t-no ()

  • gritsch schrieb:

    der compiler sieht ja selbst dass es nicht nil ist wenn es einmal geprüft wurde und dann nicht geändert wird.
    Der Analyzer sieht das.

    Natürlich können Compiler so etwas und optimieren so etwas. Aber prinzipiell ist das eine Abfrage, also eine Entscheidung, die zur Laufzeit getroffen wird, auch wenn es hier praktisch um eine Konstante und zwar genau die richtige Konstante geht. Jedoch will man ja so etwas eigentlich nicht für die *Richtigkeit* des Codes heranziehen.

    Oder anders: Die Sprache sollte ja auch noch funktionieren, wenn der Compiler strunzedumm ist und derlei wertemäßige Codezweige nicht sieht. So etwas sollte ja kein Muss für einen Compiler sein.
    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"?
  • t-no schrieb:

    Multithreading ist ja inzwischen harte Realität - ARC verdanken wir wahrscheinlich dem selben Umstand (früher war es sehr viel weniger riskant, auf das eine oder andere "retain" zu verzichten).
    Die Einführung von ARC ist völlig unabhängig von Multithreading. Und auf das ein oder andere retain zu verzichten, ist buggy, nicht riskant. (Was heißt überhaupt weniger riskant? Langsam verstehe ich, warum Apple eine Babysittersprache wollte …)

    Schützt denn if let vor Zugriffen aus anderen Threads?
    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"?