Ryan Christoffel:
But Apple’s increased trumpeting of its retail initiatives, in the face of a collective shrug from the press, made me wonder what exactly we’re all missing out on here. I mean, if the company is passionate enough about Today at Apple to host over 18,000 sessions per week, then there must be something special about the program.
[…]
At several points throughout the session, I found myself smiling just looking around the table as I considered how seemingly random a group of people this was. There were participants ranging from, by my best guess, age 13 up to those in their sixties. Two people were friends who just got new phones, and they were constantly delighted and awed by all the things they learned in the session. A mom was attending with her daughter, who was taking notes for a school report. The rest of us, by outward appearance at least, had little in common. But there we sat, around a table, learning and experimenting with the technology we share.
[…]
Instead, Apple found a creative expert to lead its training session, which has to be a more challenging hiring practice altogether. The effort is absolutely worth it though. The sense that a teacher knows what they’re talking about, and cares deeply about it, makes all the difference in the world.
Previously: October 2018 Apple Event.
Update (2018-12-10): Nikolaj Hansen-Turton:
Today at Apple at my store has been such a disappointment. They moved back to 90% being basic classes/kids swift. They need to role out the new workshops ASAP.
Apple Apple Retail Stores iOS Mac
Alexis Gallagher (tweet):
“PAT” is an acronym for Protocol with Associated Type. I coined the term in 2015 in a talk at the Swift functional programming conference that year.
That talk is a sort of a mirror of the confusion of Swift devs like myself at the time, who were excited about Swift protocols and your WWDC talk about protocol-oriented programming but also quite surprised by the limitations concerning associated types. I guessed at the motivations for this aspect of the language, relating it to other languages and to your talk. This was in the days before Swift was open-sourced, when we couldn’t just ask about these things.
I suspect many people, like me, are still a bit confused about the fundamental reason for these limitations.
[…]
Fwiw, I am sure the essential reason for the confusion then was that prototocols with associated types behaved almost exactly unlike protocols in objective-c, which was most everyone’s reference point.
Dave Abrahams:
I agree that the reference point of protocols in Objective-C was probably a source of confusion. However, I think the bigger source of confusion is that we have one thing called protocol that
- plays two distinct roles that overlap significantly in their capabilities
- can only support a fraction of its declared API in one of its roles
You can define the “existential type P” to be the most specific possible common supertype of all types conforming to the protocol P. […]
As for the fundamental reasons for this difference, it’s what I said in the talk: capturing an instance of type T as an existential type erases type information, and in particular, type relationships. If you work through a couple of examples with a protocol like […] you’ll see that the most specific common supertype of types conforming to P has no usable API. The compiler can’t provide a working init() because it has no way to know which subtype to create.
[…]
I loathe writing type-erasing wrappers as much as the next guy. But generalized existentials don’t eliminate the need to write them, nor (AFAICS) do they make it much easier to do so.
[…]
Nobody has proposed a set of features really targeted at the pain points you cite; that would be a really interesting exploration (I suspect the answer has at least as much to do with solving what I call “the API forwarding problem” as it does with existentials). Even if what is being proposed makes incremental progress toward solving those problems, though, I fear that in the specific place we arrive, having applied that increment, we’ll have done more harm than good as explained in my opening message.
Previously: Swift Protocols With Associated Types, Swift Protocols Wishlist, Patterns for Working With Associated Types, Swift Type Erasure.
See also: Type Erasers in Swift.
Language Design Programming Swift Programming Language
Tom Harrington (PDF):
Core Data brings a lot of power to an app and continues to evolve, but it can have rough spots when you’re working in Swift. What if you want to save an enum pr a struct? Does it help if your data is Codable? What’s the best way to create Swift-friendly model classes? This session will cover techniques and gotchas for integrating Core Data with your Swift code
It’s a bit of a mystery to me why Xcode’s generated code for Core Data continues to be so unhelpful compared with mogenerator.
Another option for his enum example is that, if you have the ability to change the enum’s definition, you can make it @objc enum. Then you can just declare the @NSManaged property using the proper type instead of having to write a getter and setter. The disadvantage of this, though, is that an @objc enum only shows up as the type name if you ask for its description. To see the actual case, e.g. when logging, you would need to implement CustomStringConvertible.
There are also a lot more videos from the try! Swift Conference.
Previously: Using Core Data With Swift, Generating Core Data Swift, Modern Core Data With Swift, momdec: Core Data Model Decompiler.
Code Generation Conference Core Data iOS iOS 12 Mac macOS 10.14 Mojave mogenerator Programming Swift Codable Swift Programming Language Xcode
