Like Notification.Name, I believe those types are supposed to help you
namespace your string constants when you access them. I’d recommend using a
code gen tool to generate them from your image assets, like:
extension NSImage.Name {
static let customImage = NSImage.Name(rawValue: “customImage”)
}
Which can then be used like: NSImage(named: .customImage). That’s the ultimate
use goal. It does make the old code awkward and a pain to migrate though.
Jon
> On Jul 17, 2017, at 11:20 AM, Manfred Schubert via swift-users
> <[email protected]> wrote:
>
> Why are names no longer Strings any more in Swift 4? I am all for type
> safety, but now things like
>
> NSImage(named: "Icon.png")
>
> become
>
> NSImage(named: NSImage.Name(rawValue: "Icon.png"))
>
> and
>
> NSWindowController(windowNibName: "Window")
>
> becomes
>
> NSWindowController(windowNibName: NSNib.Name(rawValue: "Window").
>
> What does this contrived way of wrapping a String into something else gain in
> me in safety in exchange for this longer and more difficult to read code? For
> me a "name" is a prime example of a String. If a name isn't one, then nothing
> is.
>
> One place where this makes a lot of sense to have is binding, and there is
> now NSBindingName. But how do I create a binding name for a property in a way
> that the compiler can check for validity? I only see the constructor from
> rawValue (String), but if I only create the binding name from a String I gain
> nothing in security.
>
>
> Kind regards,
>
> Manfred
> _______________________________________________
> swift-users mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
