iOhYes Retired


A podcast by iOS developers for iOS developers, delivering news, tips, and rants for professional iOS/Mac developers, with something for enterprise and indie developers alike.

Hosted by Darryl Thomas and John Sextro.

← Previous Episode   |   Next Episode →

66: Episode 66 - Using As with Abandon

April 28, 2015 at 6:30AM • 1 hour 6 minutes • Wiki Entry
  • WWDC
  • Swift
    • Type Casting
    • Nested Types
    • Extensions
    • Protocols

Show Notes & Links Presented by CacheFly

Tweet Shoutouts

Mutating Followup

Special thanks to Doug Whitmore (@gooddoug) for his email sharing his thoughts on "mutating".

The Discussion

  • WWDC
    • Chad is going (Darry and John are very jealous)
    • AltWWDC now AltConf 2015, a free, community-driven and supported event,
      held in downtown San Francisco alongside Apple's WWDC.
    • Apple increases scholarships from 200 to 350 to increase diversity in attendance
  • Swift
    • Type Casting
      • Implemented with “is” and “as” operators
      • Also used for checking protocol conformance (protocols must have the @objc attribute, though)
      • As has an optional/fail-able form: as?
      • Two special type aliases: AnyObject and Any
      • switch statements can be used as an effective means of branching logic based on the actual type (and value, if desired) of an Any/AnyObject
    • Nested Types
      • Provide a mechanism for confining a type to the context in which it is useful instead of polluting the “global” namespace
      • Accessed using dot-notation following the hierarchy (eg: MyClass.NestedStruct.NestedEnum.enumValue.rawValue)
      • Shorthand can be inferred based on the type
    • Extensions
      • Add new functionality to existing types
      • Access to original source is not required (retroactive modeling)
      • Analogous to Objective-C categories, but unnamed
      • Things one can do:
        • Add computed properties and computed static properties
        • Define instance methods and type methods
        • Provide new initializers
        • Define subscripts
        • Define and use new nested types
        • Make an existing type conform to a protocol
      • Things one cannot do:
        • Override existing functionality
      • Note that operators are not defined within an extension (this is true with types as well), and it makes sense when you think about it
      • Mention @iOhYesPodcast using #extensionyes or #extensionno to vote for whether extensions are a good thing or a bad thing. (Hint: they’re a good thing)
    • Protocols
      • Define a blueprint of methods, properties and “other requirements” that suit a particular task or piece of functionality
      • Can require
        • instance properties
        • instance methods
        • type methods
        • operators
        • subscripts
      • Always prefix type property/method requirements with the “class” keyword when you define them in a protocol. This rule pertains even though type property/method requirements are prefixed with the static keyword when implemented by a struct or enum!!!!
      • Any protocol you create will become a fully-fledged type for use in your code
      • You can define class-only protocols
      • You can combine protocols into a single requirement using protocol composition
      • @objc attribute allows for Objective-c interop, but using this will limit the protocol to class-only
      • Checking for protocol conformance is only possible with protocols marked with the @objc attribute, even if you’re only using Swift
      • Optional protocol requirements are supported using the optional keyword, but only if the protocol is marked with @objc




Alternative show title suggestions

  • Not, not like you
  • Perplexed
  • As?
  • I blew out your ears
  • Never gonna give you up
  • I hate’em
  • Flat out disagree
  • Team Chad
  • Cleansed my aura
  • Weird peculiarities
  • Eat my own toenails