Just one more thing - Swift thread - The Something Awful Forums

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›2 »

Toady: Jan 12, 2009

Given Apple's involvement with Clang and LLVM, I was expecting this, but not so soon.

# ¿ Jun 2, 2014 22:52

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 19:57

Toady: Jan 12, 2009

#swift-lang on Freenode is pretty active if anyone wants to stop by.

# ¿ Jun 3, 2014 03:41

Toady: Jan 12, 2009

Flappy Bird in Swift: https://github.com/fullstackio/FlappySwift

# ¿ Jun 3, 2014 18:03

Toady: Jan 12, 2009

Swift has a subreddit.

# ¿ Jun 5, 2014 05:50

Toady: Jan 12, 2009

Hughlander posted:

I hope the full slides are made available and maybe they let you loop audio to finish it.

I'd expect the full presentation to go up, but finishing the audio would also be nice. Maybe we should contact the dev tools evangelist to request this (delong@apple.com).

# ¿ Jun 5, 2014 22:08

Toady: Jan 12, 2009

It would be cool to be able to specify how Objective-C code gets presented to Swift (rdar://17184411), like with JavaScriptCore's JSExportAs(), so I could omit class prefixes or move the first parameter name out of the function name in favor of a label.

The level of Objective-C integration is impressive. I'm looking forward to converting piecemeal.

# ¿ Jun 6, 2014 08:36

Toady: Jan 12, 2009

Doctor w-rw-rw- posted:

http://openradar.appspot.com/17180612

Why yes that is definitely a constructive and useful suggestion for Swift

I recognize that guy from the Objective-C mailing list. Not that people shouldn't give their critical opinions, but he doesn't even like ARC and has been working on a perpetually delayed Objective-C performance tuning book that is arguably obsolete now for most readers.

# ¿ Jun 6, 2014 23:09

Toady: Jan 12, 2009

Implementation of Lisp cond in Swift. Demonstrates @auto_closure.

# ¿ Jun 9, 2014 00:28

Toady: Jan 12, 2009

lord funk posted:

Are property observers meant to substitute for key value observation in ObjC? It seems to me that they're very local, like having a class observe itself, but not able to be used for MVC coordination the way I've been using KVO.

As of now, you have to rely on NSObject's implementation for that kind of KVO.

# ¿ Jun 9, 2014 23:39

Toady: Jan 12, 2009

I'd be paranoid of writing to disk since Core Data would be in an undefined state.

# ¿ Jun 10, 2014 03:15

Toady: Jan 12, 2009

I'd lean on autosave and state restoration, but I'm a lazy hack. I wonder if Swift will end up with some way of working with exceptions for the sake of C++ interoperability.

# ¿ Jun 10, 2014 04:14

Toady: Jan 12, 2009

There outta be a Swift blog.

# ¿ Jun 22, 2014 09:37

Toady: Jan 12, 2009

Ender.uNF posted:

My understanding is that Chris Lattner has been pushing for some policy exceptions / changes to allow the team to have a more open development process around Swift. No word on if or when that might happen.

It would be nice to have in one place all the informative technical posts that are usually scattered across forums and blogs. Something in the vein of the Webkit blog.

# ¿ Jun 22, 2014 18:24

Toady: Jan 12, 2009

My guess is that the frameworks will start moving away from selectors and toward blocks.

# ¿ Jun 28, 2014 22:34

Toady: Jan 12, 2009

Choadmaster posted:

1) I don't file bugs anymore, I've had too many blatantly ignored (and worse, closed as "fixed" even when the detailed steps I gave to reproduce them on a fresh system still demonstrate the bug... Hello Mail) and it's a waste of my time

# ¿ Jul 5, 2014 07:08

Toady: Jan 12, 2009

eschaton posted:

I think that was referring to filing intentional duplicates to try to inflate priority, like "this bug is a duplicate of 12345, here's some text copied and pasted from a web site, I vote for this feature too!"

That was my impression. It was starting to show up on the developer forums ("here's my radar so you can dupe it").

# ¿ Jul 6, 2014 20:20

Toady: Jan 12, 2009

Also, more than once in a thread about something seemingly obvious, I've seen Corbin or some other Apple engineer say they saw no radars for it. Ever since, I always submit one unless I know I don't need to, and I make sure to explain what exactly I'm trying to do and what workarounds I've been using.

# ¿ Jul 6, 2014 20:30

Toady: Jan 12, 2009

I was hoping for this. Apple also has a WebKit blog.

# ¿ Jul 11, 2014 21:15

Toady: Jan 12, 2009

Swift is cool.

# ¿ Jul 22, 2014 01:30

Toady: Jan 12, 2009

xilni posted:

Is this one of the reasons they're not rushing to rewrite Mail.app etc... in Swift?

Mail is a shipping app with time-tested code that already works.

# ¿ Jul 31, 2014 17:24

Toady: Jan 12, 2009

lord funk posted:

Regarding lazy loading:

In some cases I've found it's nice to allow for recalculation of a property by nilling out its backing store. So in Obj-C:
Objective-C code:
- (NSArray *)someArray
{
    if (!_someArray) {
        //calculate the goods
    }
    return _someArray;
}
That array would be used until some later point where the data might change. You could then nil out _someArray, and redo the lazy loading later. My questions are:

1. Since lazy properties are only calculated once, how could this be done in Swift?
2. Or is this a bad habit of mine and there's a better way?

You're describing a cache that stores transient data. Lazy properties just lazily calculate a stored property's initial value, to defer expensive work or make use of information that isn't available when the object is initialized.

# ¿ Aug 22, 2014 18:29

Toady: Jan 12, 2009

There's work to do on Swift, but that article doesn't provide sufficient evidence or examples for some of its assertions, such as

quote:

Syntax improvements will make the Optionals more palatable, but right now their potential to create live crashes and obfuscate the code outweigh their use in making sure that the code is correct.

and

quote:

The contorted if ((self = [super init])) { } return self; is something that makes grown men cry, and is probably the single biggest reason why people use fewer classes in ObjC compared to languages like Java and C++.

# ¿ Oct 2, 2014 01:00

Toady: Jan 12, 2009

quote:

This Thanksgiving when you sit down for dinner thankful for the increase in Apple stock option value, remember all the little developers you have trampled on with this arrogance.

Sometimes the developer forums make me smile.

# ¿ Oct 10, 2014 19:53

Toady: Jan 12, 2009

My waking nightmare.

# ¿ Oct 27, 2014 02:12

Toady: Jan 12, 2009

In an OS X project, I have an embedded framework with a Connection class that has an embedded struct type called Settings. In my application, when I create an instance of Connection.Settings and pass it to a connection method that takes a Connection.Settings argument, I get:

code:

'Connection.Settings' is not convertible to 'Connection.Settings'

Edit: I traced the issue to a framework target that was no longer in the project. I had created a new embedded framework and copied class files from the old target to the new target. The old framework was still around despite cleaning the build.

Toady fucked around with this message at 00:46 on Dec 4, 2014

# ¿ Dec 4, 2014 00:31

Toady: Jan 12, 2009

Xcode 6.3b1 is out, with changes significant enough to warrant a code migrator.

# ¿ Feb 9, 2015 19:51

Toady: Jan 12, 2009

One weird tip to cause a segfault (19585191):

code:

class Crasher {
    var foo: [foo]? { return nil }
}

# ¿ Feb 9, 2015 23:51

Toady: Jan 12, 2009

I wonder what, if anything, changed from the most recent beta.

# ¿ Apr 8, 2015 22:32

Toady: Jan 12, 2009

I file Swift bugs under Developer Tools.

# ¿ May 13, 2015 01:31

Toady: Jan 12, 2009

The Swift blog has a post on 2.0 with a summary of new things. try-catch has arrived.

Edit: More on the Swift marketing page.

Toady fucked around with this message at 22:13 on Jun 8, 2015

# ¿ Jun 8, 2015 21:51

Toady: Jan 12, 2009

A prerelease version of the Swift 2 book is available.

# ¿ Jun 8, 2015 23:04

Toady: Jan 12, 2009

I'm migrating classes in a large Objective-C project to Swift. I've found that if you expose a Swift class using a custom name via @objc, the Swift class can no longer see methods in Objective-C classes that reference that name.

Example:

code:

// TestFoo.h

@import Foundation;
@class TestBar;

@interface TestFoo : NSObject

@property (weak) TestBar *bar;

- (instancetype)initWithBar:(TestBar *)bar;

@end

code:

// TestFoo.m

#import "TestFoo.h"
#import "Test-Swift.h"

@implementation TestFoo

- (instancetype)initWithBar:(TestBar *)bar {
    self = [super init];
    if (self) {
        _bar = bar;
    }
    return self;
}
@end

code:

// Bar.swift

import Foundation

@objc(TestBar)
class Bar: NSObject {

    override init() {
        let foo = TestFoo(bar: self) // Error: Extra argument 'bar' in call
    }
}

Is there a solution for this?

# ¿ Nov 25, 2015 20:36

Toady: Jan 12, 2009

I filed rdar://23666040 with a sample project containing the code posted here.

# ¿ Nov 25, 2015 21:08

Toady: Jan 12, 2009

Doctor w-rw-rw- posted:

Now I'll have to satisfy my neckbeard impulse to demand virtually impossible things by complaining that Core Data isn't open-source!

There's already a GPLv3 relicensing PR, in addition to the expected typo PRs.

# ¿ Dec 3, 2015 21:03

Toady: Jan 12, 2009

squidgee posted:

I agree. One of the things I actually love about Cocoa is the verbosity of the APIs, and how the method names make it completely obvious what they do and how to use them. It makes reading other people's code, or my own old code, so much less painful.

This just seems like brevity for brevity's sake. I don't like it at all.

As an opposing view, I'm burned out from the verbosity of Objective-C APIs and find it a real chore at times.

# ¿ Jan 31, 2016 03:32

Toady: Jan 12, 2009

Kallikrates posted:

I also think the point examples are a little too simplistic as lord funk shows. We're told to remove as much redundant type info and rely on inference as much as possible.
string.writeTo(filePath, atomically: ...)
Scanning that code 6 moths from now I am definitely not going to remember if filePath was a URI or String. If I have to fall back to hungarian notation-ish I think readability/scannability has suffered. This proposal asks more from callers in terms variable length/descriptiveness (stuff we write) in order to trim API verbosity: stuff xcode and or auto completes writes for us.

The current style doesn't tell you the type of filePath either. However, alt-clicking the variable in Xcode will show you its type. The argument about not knowing what type a variable is has always felt contrived to me.

# ¿ Jan 31, 2016 17:27

Toady: Jan 12, 2009

squidgee posted:

Right - this change just trades one kind of verbosity for another. Instead of writeToURL(filePath), I'll have code that looks like writeTo(filePathString) or writeTo(filePathURL) or whatever. Then, because this naming pattern is totally optional, I'll inevitably forget to use it at some point and write stuff that's confusing to re-read later.

The existing verbose method names save me from myself, and make unfamiliar APIs and codebases easier to navigate, even if they can be annoying at times.

Many Cocoa APIs don't describe types in their selectors. What does -compare: compare to? What type of suffix does -hasSuffix: take? What does -executeFetchRequest:error: return? In Swift, we already leave off type information most of the time when declaring constants and variables, and Xcode can not only supply this information but take you to declarations on cmd-click, so I think this argument feels contrived. Other arguments against the change exist, but this one doesn't feel persuasive to me.

Toady fucked around with this message at 18:47 on Jan 31, 2016

# ¿ Jan 31, 2016 18:39

Toady: Jan 12, 2009

But your example is deliberately using the non-descriptive method name foo, so naturally it's confusing and lacking in context. I'm fine with edge cases like Int32(1) standing out with an initializer because explicitly sized integers are rare/discouraged in Swift. Such a method would likely only accept Int arguments and leave it to clients of the API to convert any weird fixed width integers they're using for some reason.

I don't understand what you mean with the tuple-based addLineTo((100,100)) example, since my understanding is that the translation will be like this:

code:

addLineTo(CGPoint(x: 100, y: 100))

Developers should already be using descriptive variable names like filePath, cursorPoint, boxSize, etc. so I just don't find the argument about variable names convincing. Bad variable names in lovely code would be a problem regardless of this change. I feel like there are valid arguments to be made against the API changes but that people are focusing on trivial or contrived examples to make their case.

Toady fucked around with this message at 20:52 on Jan 31, 2016

# ¿ Jan 31, 2016 20:29

Toady: Jan 12, 2009

I just don't see Cocoa or any reasonably-designed API running into that situation, especially Swift-specific frameworks that avoid AnyObject entirely.

# ¿ Jan 31, 2016 21:06

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 19:57

Toady: Jan 12, 2009

Doctor w-rw-rw- posted:

You're focusing on the wrong thing. It doesn't require AnyObject.

...

"A reasonably-designed API" is incredibly optimistic. This opens a big fat , and shortening the API methods makes it incredibly easy to screw things up. I'm writing code that already compiles, and managing to shoot myself in the foot. Now imagine giving sidearms to every single bridged API and saying "as long as you don't point this at your foot, you'll be fine" is going to result in way more bleeding feet than necessary.

It barely matters that the examples are slightly contrived, IMO, because it's still not a hard problem to stumble across, and trivially avoidable at that.

Overload gotchas are a known quirk--what I was getting at with regards to APIs that avoid AnyObject was the convention of using a protocol type, though overloads can still be introduced via extensions and subclasses (at least until final is default). At that point, I still don't see people's bad decisions as a strike against the style change.

squidgee posted:

Also, I'd be remiss if I didn't point out that we've all just spent several pages bike shedding.

It's not really bike shedding because it's a non-trivial change with potentially large repercussions that are interesting to discuss in a less formal setting than the mailing list.

Toady fucked around with this message at 23:00 on Jan 31, 2016

# ¿ Jan 31, 2016 22:49

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›2 »