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.
Yeah, this is the intended use pattern for these namespaced constant. You don't need the `rawValue:` label, though:
extension NSImage.Name {
static let myImage = Name("myImage")
}
-Joe
···
On Jul 17, 2017, at 8:26 AM, Jon Shier via swift-users <swift-users@swift.org> wrote:
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.
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 <swift-users@swift.org> wrote:
Why are names no longer Strings any more in Swift 4? I am all for type safety, but now things like
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.
It would be possible to do the same thing as an extension to String without making the default/simple case more complicated. So I would have said this is overkill, but I'm fine with it.
What remains is the question whether it is possible to create NSBindingNames in a safe way, like from selector().
Kind regards,
Manfred
···
Am 17.07.2017 um 17:47 schrieb Joe Groff <jgroff@apple.com>:
Yeah, this is the intended use pattern for these namespaced constant. You don't need the `rawValue:` label, though:
extension NSImage.Name {
static let myImage = Name("myImage")
}
Yeah, this is the intended use pattern for these namespaced constant. You don't need the `rawValue:` label, though:
extension NSImage.Name {
static let myImage = Name("myImage")
}
It would be possible to do the same thing as an extension to String without making the default/simple case more complicated. So I would have said this is overkill, but I'm fine with it.
By making it a separate type, though, it lets you define constants without polluting String's namespace, and lets the type system prevent typos or accidental misuse of a name.
What remains is the question whether it is possible to create NSBindingNames in a safe way, like from selector().
If you want to ensure that the string value corresponds to a declaration, maybe you could use keypath, which ought to be interchangeable with a string literal but checked by the compiler.
-Joe
···
On Jul 17, 2017, at 9:04 AM, Manfred Schubert <dev@schubert-it.com> wrote:
Am 17.07.2017 um 17:47 schrieb Joe Groff <jgroff@apple.com>:
Making them an extension on String makes them visible everywhere String is used, unless you limit the visibility in some way, which impacts the performance of autocomplete and fills it with random constants. Like I said, part of the reason for this is to separate the constants.
Jon
···
On Jul 17, 2017, at 12:04 PM, Manfred Schubert <dev@schubert-it.com> wrote:
Am 17.07.2017 um 17:47 schrieb Joe Groff <jgroff@apple.com>:
Yeah, this is the intended use pattern for these namespaced constant. You don't need the `rawValue:` label, though:
extension NSImage.Name {
static let myImage = Name("myImage")
}
It would be possible to do the same thing as an extension to String without making the default/simple case more complicated. So I would have said this is overkill, but I'm fine with it.
What remains is the question whether it is possible to create NSBindingNames in a safe way, like from selector().
Am 17.07.2017 um 18:08 schrieb Jon Shier <jon@jonshier.com>:
Making them an extension on String makes them visible everywhere String is used, unless you limit the visibility in some way, which impacts the performance of autocomplete and fills it with random constants.
Am 17.07.2017 um 18:12 schrieb Joe Groff <jgroff@apple.com>:
If you want to ensure that the string value corresponds to a declaration, maybe you could use keypath, which ought to be interchangeable with a string literal but checked by the compiler.
Could / should these types be ExpressibleByStringLiteral?
Nevin
···
On Mon, Jul 17, 2017 at 12:47 PM, Manfred Schubert via swift-users < swift-users@swift.org> wrote:
> Am 17.07.2017 um 18:08 schrieb Jon Shier <jon@jonshier.com>:
>
> Making them an extension on String makes them visible everywhere String
is used, unless you limit the visibility in some way, which impacts the
performance of autocomplete and fills it with random constants.
They should not. We are deliberately discouraging the string literal of the name. The string literal should be in only one place: the definition of the name constant. Everything else should use the constant. The compiler can provide autocompletion and typo detection of the constant. The string literal doesn't get that.
···
On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users <swift-users@swift.org> wrote:
Could / should these types be ExpressibleByStringLiteral?
The thing is, with Notification.Name, you have to use them at least twice. So everybody is creating a constant. And typos in the String that defines the constant don't matter. So this solves the problem. With NSNib however, the default case is to use the name only once. And I would say with NSImage it's probably the same. I don't think people have been defining constants for these when they are only used once. It makes the code unnecessarily longer and more complicated. And a typo in the String that defines the constant matter just as much as a typo in the String literal. So in the default case this doesn't solve a problem.
Kind regards,
Manfred
···
Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users <swift-users@swift.org>:
On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users <swift-users@swift.org> wrote:
Could / should these types be ExpressibleByStringLiteral?
They should not. We are deliberately discouraging the string literal of the name. The string literal should be in only one place: the definition of the name constant. Everything else should use the constant. The compiler can provide autocompletion and typo detection of the constant. The string literal doesn't get that.
I think this should be a feature of Xcode to automatically generate / maintain these constants: When you add assets or create interface builder files, a plug-in could take care of generating / updating such constants and you would get auto-complete and type safety for free.
···
On Jul 18, 2017, at 3:56 AM, Manfred Schubert via swift-users <swift-users@swift.org> wrote:
Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users <swift-users@swift.org>:
On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users <swift-users@swift.org> wrote:
Could / should these types be ExpressibleByStringLiteral?
They should not. We are deliberately discouraging the string literal of the name. The string literal should be in only one place: the definition of the name constant. Everything else should use the constant. The compiler can provide autocompletion and typo detection of the constant. The string literal doesn't get that.
The thing is, with Notification.Name, you have to use them at least twice. So everybody is creating a constant. And typos in the String that defines the constant don't matter. So this solves the problem. With NSNib however, the default case is to use the name only once. And I would say with NSImage it's probably the same. I don't think people have been defining constants for these when they are only used once. It makes the code unnecessarily longer and more complicated. And a typo in the String that defines the constant matter just as much as a typo in the String literal. So in the default case this doesn't solve a problem.
I'd agree with that. Fortunately there are tools out there that can parse such things and generate the constants for us already. Waiting for Xcode to implement such common sense quality of life improvements probably won't end. I'll file bugs in the meantime though.
Jon
···
On Jul 18, 2017, at 1:38 PM, Hooman Mehr via swift-users <swift-users@swift.org> wrote:
I think this should be a feature of Xcode to automatically generate / maintain these constants: When you add assets or create interface builder files, a plug-in could take care of generating / updating such constants and you would get auto-complete and type safety for free.
On Jul 18, 2017, at 3:56 AM, Manfred Schubert via swift-users <swift-users@swift.org> wrote:
Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users <swift-users@swift.org>:
On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users <swift-users@swift.org> wrote:
Could / should these types be ExpressibleByStringLiteral?
They should not. We are deliberately discouraging the string literal of the name. The string literal should be in only one place: the definition of the name constant. Everything else should use the constant. The compiler can provide autocompletion and typo detection of the constant. The string literal doesn't get that.
The thing is, with Notification.Name, you have to use them at least twice. So everybody is creating a constant. And typos in the String that defines the constant don't matter. So this solves the problem. With NSNib however, the default case is to use the name only once. And I would say with NSImage it's probably the same. I don't think people have been defining constants for these when they are only used once. It makes the code unnecessarily longer and more complicated. And a typo in the String that defines the constant matter just as much as a typo in the String literal. So in the default case this doesn't solve a problem.