Re: [swift-users] What is up with names not being Strings any more in Swift 4?

[Jon Shier via swift-users]

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 
>  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 
>>  wrote:
>> 
>> 
>>> Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users 
>>> :
>>> 
>>> 
 On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users 
  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.
>> 
>> 
>> Kind regards,
>> 
>> Manfred
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is up with names not being Strings any more in Swift 4?

[Hooman Mehr via swift-users]

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 
>  wrote:
> 
> 
>> Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users 
>> :
>> 
>> 
>>> On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users 
>>>  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.
> 
> 
> Kind regards,
> 
> Manfred
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is up with names not being Strings any more in Swift 4?

[Manfred Schubert via swift-users]

> Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users 
> :
> 
> 
>> On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users 
>>  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.


Kind regards,

Manfred
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is up with names not being Strings any more in Swift 4?

[Greg Parker via swift-users]

> On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users 
>  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. 


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is up with names not being Strings any more in Swift 4?

[Nevin Brackett-Rozinsky via swift-users]

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 :
> >
> > 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.
>
> I see. Thanks for clarifying.
>
>
> Manfred
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is up with names not being Strings any more in Swift 4?

[Jon Shier via swift-users]

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  wrote:
> 
> 
>> Am 17.07.2017 um 17:47 schrieb Joe Groff :
>> 
>> 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().
> 
> 
> Kind regards,
> 
> Manfred

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is up with names not being Strings any more in Swift 4?

[Joe Groff via swift-users]

> On Jul 17, 2017, at 9:04 AM, Manfred Schubert  wrote:
> 
> 
>> Am 17.07.2017 um 17:47 schrieb Joe Groff :
>> 
>> 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
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is up with names not being Strings any more in Swift 4?

[Joe Groff via swift-users]

> On Jul 17, 2017, at 8:26 AM, Jon Shier via swift-users 
>  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.

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
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] What is up with names not being Strings any more in Swift 4?

[Jon Shier via swift-users]

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 
>  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
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users