Swift-evolution

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

  • tsunamix schrieb:

    Wollen wir alle, wirklich alle dirty hacks lesen wollen, die die da so so machen...? *grübel*
    Wahrscheinlich sind die genau der Haupthinderungsgrund. Da könnte man wahrscheinlich auch einiges daraus lernen. Andererseits hätte Apple bei den Bedienungsänderungen nicht mehr ganz so viel Freiheit.

    +träum+ und vielleicht hätte Xcode auch ein paar Bugs weniger. ;)
    „Meine Komplikation hatte eine Komplikation.“

  • t-no schrieb:

    Wenn's mit Xcode nur auch so voran gehen würde... ;)
    Jo:

    1. PP herausschmeißen: Bruche mer nit
    2. Oh, braucht man doch
    3. Partiellen Ersatz einfügen
    4. TOTAL MODERN! schreiben

    Hatten die das Spiel nicht schon mit der bedingten Kompilierung?
    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"?

  • Swift 3.0 Release Process

    NIcht nur meckern. Ich find's ehrlich gesagt auch mal ganz nett vorab wissen zu können, wann und wohin es gehen soll. Objective-C 2 war ja ein so transparenter Prozeß, bei dem jeder wußte, wann er wohin führt...
    Nun ja, Wie dem auch sei...

    O.g. Link klingt m.M.n. u.a. nach einer vorab Weichenstellung für die WWDC.
    not source-compatible
    Klingt ehrlich gesagt nach einer maßlosen Untertreibung. Soweit ich das verfolgt und mit aktuellen 3.0 builds 'gespielt‘ habe, wird so ziemlich jede zweite Codezeile davon betroffen sein. Davon werden wahrscheinlich ca. 10 bis 20% auch nicht automatisch konvertiert werden können, soweit ich das bis jetzt einschätzen kann.

    Ich bezweifle, daß der Zeitplan "Ende 2016" eingehalten werden kann, bzw. werden sollte.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • macmoonshine schrieb:

    torquato schrieb:

    Objective-C 2 war ja ein so transparenter Prozeß, bei dem jeder wußte, wann er wohin führt...
    Naja, Objective-C hat sich in den letzten 30 Jahren ja auch kaum verändert. Die paar Anpassungen gehen ja bei Swift als Bugfix-Release durch. ;) +scnr+
    Objective-C war ja auch nicht wirklich von Apple :)

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    macmoonshine schrieb:

    torquato schrieb:

    Objective-C 2 war ja ein so transparenter Prozeß, bei dem jeder wußte, wann er wohin führt...
    Naja, Objective-C hat sich in den letzten 30 Jahren ja auch kaum verändert. Die paar Anpassungen gehen ja bei Swift als Bugfix-Release durch. ;) +scnr+
    Objective-C war ja auch nicht wirklich von Apple :)
    Gruß

    Claus
    Apple hatte nur einmal ein glückliches Händchen bei Programmiersprachen, als sie NeXT gekauft haben.

    Bei Swift habe ich den Eindruck, dass die Freigabe des Weiterentwicklungsprozesses als Open-Source der Bestie Tür und Tor geöffnet hat. ;) :D
    „Meine Komplikation hatte eine Komplikation.“

  • Ich sehe einfach keinen Sinn darin OOP Sprache durch eine andere OOP Sprache zu ersetzen.

    Wenn es jetzt ein super neues Konzept gäbe, wie man grundsätzlich anders an die Erstellung einer Software herangehen würde, dann macht es einen Sinn.

    Meinetwegen hätten sie auch den genzen Hirnschmalz der da verbraten wurde, dafür aufwenden können die IDE so zu erweitern, dass man immer mehr mit Klicken seine Software zummenbauen kann um es den Kiddies zu erleichtern dass sie nicht mehr soviel lernen müssen. Scheint ja der neue Stil zu werden.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:


    Meinetwegen hätten sie auch den genzen Hirnschmalz der da verbraten wurde, dafür aufwenden können die IDE so zu erweitern, dass man immer mehr mit Klicken seine Software zummenbauen kann um es den Kiddies zu erleichtern dass sie nicht mehr soviel lernen müssen. Scheint ja der neue Stil zu werden.
    Für den neuen Stil müssten sie in XCode nur einen Menüpunkt einfügen: "Edit -> Insert random Stackoverflow code"
    Multigrad - 360°-Produktfotografie für den Mac

  • Nun ja, wenn man mal so bedenkt was aus anderen ehemals closed source Produkten wurde, die dann Open Source wurden...

    Beispiel OpenOffice. War frei. Wurde von Sun gekauft und geschlossen. Als Sun von Oracle übernommen wurde, wurde der Kram nach kurzer Zeit an die Apache Community ausgelagert. OpenOffice ist tot.
    LibreOffice ist der OOo Fork, der jetzt die höchste Verbreitung und die aktivste Gestaltung erfährt.

    Ich bin guter Dinge, dass es Swift ganz genau so gehen wird. ^^
    «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

  • Was mir am Xcode auch negativ aufstößt ist dass ich ältere SDKs brauche. Die müssen ja nicht direkt bei der installation dabei sein, aber sie sollten sich nachladen lassen.
    So muss ich die alten SDKs jedesmal manuell aus dem alten Xcode fischen und ins neue Xcode bundle wieder reinpacken (an die richtige stelle).

    Und jetzt kommt mir nicht damit dass ich einfach immer mit dem neusten SDK builden soll denn dann reist mir die QA den kopf ab.
    Wenn version X.Y mit SDK 10.9 gebuildet wurde und nun ein schneller bugfix rein soll (X.Y.1), so muss ich das auch wieder mit dem 10.9er SDK builden und nicht mit dem 10.11er sonst braucht QA zwei wochen für einen "komplett-test"...

  • gritsch schrieb:

    So muss ich die alten SDKs jedesmal manuell aus dem alten Xcode fischen und ins neue Xcode bundle wieder reinpacken (an die richtige stelle).
    Du kannst auch die ältere Xcode-Version (komplett) irgendwo installieren, und über Preferences -> Locations oder xcode-select das SDK auswählen, das du brauchst.

    Falls du Teile mit make(1) bzw. die Kommandozeile baust, kannst du auch die Umgebungsvariable DEVELOPER_DIR auf das Developer-Verzeichnis setzen, das das gewünschte SDK enthält.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    gritsch schrieb:

    So muss ich die alten SDKs jedesmal manuell aus dem alten Xcode fischen und ins neue Xcode bundle wieder reinpacken (an die richtige stelle).
    Du kannst auch die ältere Xcode-Version (komplett) irgendwo installieren, und über Preferences -> Locations oder xcode-select das SDK auswählen, das du brauchst.
    Falls du Teile mit make(1) bzw. die Kommandozeile baust, kannst du auch die Umgebungsvariable DEVELOPER_DIR auf das Developer-Verzeichnis setzen, das das gewünschte SDK enthält.
    ist imr klar, hab ich dann aber zwei projekte offen die unterschiedliche SDKs verwenden dann führt es dazu dass ich zwei verschiedene Xcode versionen laufen haben müsste und das geht dann in die hose...

  • mattik schrieb:

    Thallius schrieb:

    Meinetwegen hätten sie auch den genzen Hirnschmalz der da verbraten wurde, dafür aufwenden können die IDE so zu erweitern, dass man immer mehr mit Klicken seine Software zummenbauen kann um es den Kiddies zu erleichtern dass sie nicht mehr soviel lernen müssen. Scheint ja der neue Stil zu werden.
    Für den neuen Stil müssten sie in XCode nur einen Menüpunkt einfügen: "Edit -> Insert random Stackoverflow code"
    Das ist nicht ganz so einfach: Wie willst du sicherstellen, dass der eingefügte Code garantiert nicht verstanden wurde?
    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"?