Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[David Waite via swift-evolution]

I don’t think the API of types have to be bulletproof from the start, but it 
shouldn’t have core usage limitations based on Objective C. One example would 
be if I have to deal with NSNumber/NSString/NSArray/NSDictionary to fully use 
the API, such as NSAttributedString or NSError.

The issue is that Foundation is both the objective-c compatibility base and the 
cross-platform foundational library for Swift. These goals conflict. Without an 
idea of how the Swift flavor of Foundation will evolve in the future to deal 
with this conflict, it is hard to evaluate this other than saying “will be 
confusing why some Objective-C things have prefixes and others don’t” and “will 
cause conflicts with non-Apple foundational libraries”.

-DW


> On May 17, 2016, at 7:41 AM, Matt Whiteside via swift-evolution 
>  wrote:
> 
> I meant to say that it sounds like a good idea to leave the ’NS’ prefix on 
> types that were auto-translated, and remove it from those that have been 
> rewritten by hand for swift.
> 
> -Matt
> 
>> On May 16, 2016, at 21:24, Matt Whiteside > > wrote:
>> 
>> This sounds like a good idea.
>> 
>> -Matt
>> 
>>> On May 10, 2016, at 03:43, Geordie Jay via swift-evolution 
>>> > wrote:
>>> 
>>> 
 Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution 
 >:
 
 
> What is your evaluation of the proposal?
 Personally I’m a -1; I’d prefer to see the NS prefix remain on types that 
 have been translated automatically with minimal human interaction, in 
 favour of dropping the prefix for types that have received more attention 
 to establish a Swift-ier style, but migrating these into a new module 
 instead.
>>> 
>>> I strongly agree with keeping NS prefix on API that has not been 
>>> ‘Swiftified'. First step, achieve functional equivalence with Darwin APIs. 
>>> Second step, systematically improve Foundation to the point where it feels 
>>> like this fundamental part of the language is as easy to use and idiomatic 
>>> as the standard library itself. At that point I’d be very much for dropping 
>>> the prefixes.
>>> 
 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
 Since it’s a basic API that most developers will be interacting with then 
 yes, even though the change is fairly minor, it definitely bears 
 consideration.
 
> Does this proposal fit well with the feel and direction of Swift?
 Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at 
 the same time this is why I’d like to keep the current convention for 
 existing (unchanged) types, as it makes it much clearer that these are 
 things that weren’t originally designed for Swift and thus won’t behave 
 quite as you might expect.
>>> 
>>> Completely agree
>>> 
 
> If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
 I’ve worked in languages where libraries had different styles of 
 name-spacing, and while it was annoying to have a mixture, I think it was 
 fine, especially for libraries that are older, as the prefix name-spacing 
 style makes it absolutely clear that this is an older API.
 
>>> 
>>> Yes, we should be clear this is an older API, also to add motivation on 
>>> introducing a more modern one (even if at first it just wraps Foundation 
>>> with a more Swift-like API)
>>> 
> How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
 
 Quick read of the proposal, kept an eye on the discussion leading up to it 
 though.
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Matt Whiteside via swift-evolution]

I meant to say that it sounds like a good idea to leave the ’NS’ prefix on 
types that were auto-translated, and remove it from those that have been 
rewritten by hand for swift.

-Matt

> On May 16, 2016, at 21:24, Matt Whiteside  wrote:
> 
> This sounds like a good idea.
> 
> -Matt
> 
>> On May 10, 2016, at 03:43, Geordie Jay via swift-evolution 
>> > wrote:
>> 
>> 
>>> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution 
>>> >:
>>> 
>>> 
 What is your evaluation of the proposal?
>>> Personally I’m a -1; I’d prefer to see the NS prefix remain on types that 
>>> have been translated automatically with minimal human interaction, in 
>>> favour of dropping the prefix for types that have received more attention 
>>> to establish a Swift-ier style, but migrating these into a new module 
>>> instead.
>> 
>> I strongly agree with keeping NS prefix on API that has not been 
>> ‘Swiftified'. First step, achieve functional equivalence with Darwin APIs. 
>> Second step, systematically improve Foundation to the point where it feels 
>> like this fundamental part of the language is as easy to use and idiomatic 
>> as the standard library itself. At that point I’d be very much for dropping 
>> the prefixes.
>> 
>>> 
 Is the problem being addressed significant enough to warrant a change to 
 Swift?
>>> Since it’s a basic API that most developers will be interacting with then 
>>> yes, even though the change is fairly minor, it definitely bears 
>>> consideration.
>>> 
 Does this proposal fit well with the feel and direction of Swift?
>>> Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at 
>>> the same time this is why I’d like to keep the current convention for 
>>> existing (unchanged) types, as it makes it much clearer that these are 
>>> things that weren’t originally designed for Swift and thus won’t behave 
>>> quite as you might expect.
>> 
>> Completely agree
>> 
>>> 
 If you have used other languages or libraries with a similar feature, how 
 do you feel that this proposal compares to those?
>>> I’ve worked in languages where libraries had different styles of 
>>> name-spacing, and while it was annoying to have a mixture, I think it was 
>>> fine, especially for libraries that are older, as the prefix name-spacing 
>>> style makes it absolutely clear that this is an older API.
>>> 
>> 
>> Yes, we should be clear this is an older API, also to add motivation on 
>> introducing a more modern one (even if at first it just wraps Foundation 
>> with a more Swift-like API)
>> 
 How much effort did you put into your review? A glance, a quick reading, 
 or an in-depth study?
>>> 
>>> Quick read of the proposal, kept an eye on the discussion leading up to it 
>>> though.
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Matt Whiteside via swift-evolution]

This sounds like a good idea.

-Matt

> On May 10, 2016, at 03:43, Geordie Jay via swift-evolution 
>  wrote:
> 
> 
>> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution 
>> >:
>> 
>> 
>>> What is your evaluation of the proposal?
>> Personally I’m a -1; I’d prefer to see the NS prefix remain on types that 
>> have been translated automatically with minimal human interaction, in favour 
>> of dropping the prefix for types that have received more attention to 
>> establish a Swift-ier style, but migrating these into a new module instead.
> 
> I strongly agree with keeping NS prefix on API that has not been 
> ‘Swiftified'. First step, achieve functional equivalence with Darwin APIs. 
> Second step, systematically improve Foundation to the point where it feels 
> like this fundamental part of the language is as easy to use and idiomatic as 
> the standard library itself. At that point I’d be very much for dropping the 
> prefixes.
> 
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> Since it’s a basic API that most developers will be interacting with then 
>> yes, even though the change is fairly minor, it definitely bears 
>> consideration.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at 
>> the same time this is why I’d like to keep the current convention for 
>> existing (unchanged) types, as it makes it much clearer that these are 
>> things that weren’t originally designed for Swift and thus won’t behave 
>> quite as you might expect.
> 
> Completely agree
> 
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> I’ve worked in languages where libraries had different styles of 
>> name-spacing, and while it was annoying to have a mixture, I think it was 
>> fine, especially for libraries that are older, as the prefix name-spacing 
>> style makes it absolutely clear that this is an older API.
>> 
> 
> Yes, we should be clear this is an older API, also to add motivation on 
> introducing a more modern one (even if at first it just wraps Foundation with 
> a more Swift-like API)
> 
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>> 
>> Quick read of the proposal, kept an eye on the discussion leading up to it 
>> though.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Dan Appel via swift-evolution]

-1 for all the reasons given so far. Foundation is not a Swift API and the
NS prefixes help users understand that. Until Foundation gets an API
rewrite that makes it feel native in the Swift ecosystem, it should be made
very clear that it is a legacy API and not necessary following Swift best
practices. I'm actually quite surprised that the Swift team decided to
reimplement Foundation with 100% api compatibility, rather than building a
"new and improved" version from scratch.

On Mon, May 16, 2016 at 6:37 PM Rob Mayoff via swift-evolution <
swift-evolution@swift.org> wrote:

> We (you) shouldn't remove the NS prefixes from most of the classes in
> the proposal. I agree with the reasons the other naysayers have given,
> but I'll try to restate them in my own words.
>
> Swift needs a better namespace/import system before these classes
> should lose the NS prefix. Right now, you cannot just import one name
> from a module. (If you think you can, try typing “import
> Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be
> selective about what loses the NS prefix.
>
> For any type, some fraction of programs need to mention the type by
> name in order to justify a prefixless name. What should that threshold
> be? Fifty percent? Ten percent? Five percent? String and Int and a
> bunch of other types in the standard library can pass a reasonable
> threshold. What fraction of programs mention NSTask? NSPort? NSHost?
> NSScanner?
>
> For any name, some fraction of programs would want to use that term
> for a program-specific type different than the Foundation type. What
> fraction is high enough to justify prefixing the Foundation type name?
> E.g. are there enough datebook programs that think "Calendar" should
> mean the user's schedule of events, so that Foundation shouldn't claim
> the generic term "Calendar"? How about "Timer"? "Task"? "Port"?
> "Host"?
>
> What fraction of these Foundation types would have a substantially
> different API if they were designed from scratch in the age of Swift
> with the experience of Foundation? Example: NSDate. Looking at each of
> JodaTime, NodaTime, and boost::date_time, I see a type representing a
> calendar date (e.g. 2016-05-16) with no associated time of day. I've
> seen and answered enough questions on stackoverflow to know that iOS
> programmers want a type like that. A from-scratch Swift date/time
> library would be justified in having such a type, and "Date" would be
> a great name for that type (with a prefix or nested in another type,
> unless Swift gets a better namespace/import system). NSDate represents
> the same thing as CFAbsoluteTime, and should have a name more
> representative of that.
>
> I just don't see the benefit of stripping the NS prefix from most of
> the types in Foundation, given the state of those types and the state
> of Swift.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Dan Appel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Rob Mayoff via swift-evolution]

We (you) shouldn't remove the NS prefixes from most of the classes in
the proposal. I agree with the reasons the other naysayers have given,
but I'll try to restate them in my own words.

Swift needs a better namespace/import system before these classes
should lose the NS prefix. Right now, you cannot just import one name
from a module. (If you think you can, try typing “import
Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be
selective about what loses the NS prefix.

For any type, some fraction of programs need to mention the type by
name in order to justify a prefixless name. What should that threshold
be? Fifty percent? Ten percent? Five percent? String and Int and a
bunch of other types in the standard library can pass a reasonable
threshold. What fraction of programs mention NSTask? NSPort? NSHost?
NSScanner?

For any name, some fraction of programs would want to use that term
for a program-specific type different than the Foundation type. What
fraction is high enough to justify prefixing the Foundation type name?
E.g. are there enough datebook programs that think "Calendar" should
mean the user's schedule of events, so that Foundation shouldn't claim
the generic term "Calendar"? How about "Timer"? "Task"? "Port"?
"Host"?

What fraction of these Foundation types would have a substantially
different API if they were designed from scratch in the age of Swift
with the experience of Foundation? Example: NSDate. Looking at each of
JodaTime, NodaTime, and boost::date_time, I see a type representing a
calendar date (e.g. 2016-05-16) with no associated time of day. I've
seen and answered enough questions on stackoverflow to know that iOS
programmers want a type like that. A from-scratch Swift date/time
library would be justified in having such a type, and "Date" would be
a great name for that type (with a prefix or nested in another type,
unless Swift gets a better namespace/import system). NSDate represents
the same thing as CFAbsoluteTime, and should have a name more
representative of that.

I just don't see the benefit of stripping the NS prefix from most of
the types in Foundation, given the state of those types and the state
of Swift.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Kevin Ballard via swift-evolution]

On Mon, May 9, 2016, at 03:20 PM, Douglas Gregor via swift-evolution wrote:
>  * What is your evaluation of the proposal?
 
+1 to enum renaming / hoisting, including turning NSStringEncoding into
an enum, but -1 on dropping the NS prefix. I agree with a lot of what
the other -1 people have said, but the 2 biggest reasons for me are:
 
1. The NS prefix is a signal that the type is probably an Objective-C
   class, and with the enum renaming/hoisting this signal will become
   even stronger. The fact that it's an Objective-C class means that
   it's not Swift-like, it's a reference type, it doesn't participate in
   copy-on-write mutation, etc.
 
2. Dropping the NS prefix means that a *lot* of pretty generic names are
   now owned by Foundation, which makes it difficult to implement the
   same concept in the Swift standard library. A lot of these names
   aren't likely to end up in the Swift stdlib, but I'd rather be
   cautious about this and not take any of these names.
 
By keeping the NS prefixes, we can then "swiftify" these APIs on an
ongoing basis and drop the prefix once a type has been "swiftified"
(which includes turning things into value types when applicable, not
merely renaming methods). And if done right, the swiftified types can
operate without Foundation at all, the same way
String/Array/Dictionary/Set are independent implementations that bridge
to/from Obj-C.
 
As a side note, regardless of everything else, we really should not
rename NSJSONSerialization to JSONSerialization. This class is a
specific implementation of a JSON encoder/decoder that operates on
Foundation types. The name JSONSerialization should be reserved for the
potential use of a Swift-native JSON encoder/decoder.

>  * Is the problem being addressed significant enough to warrant a
>change to Swift?
 
I don't think so. I'm not sure what the benefit of dropping the "NS"
prefix is supposed to be at all, besides saving 2 keystrokes. The
proposal says this is to "establish these libraries as fundamental and
native Swift libraries" by "making their naming style match the
convention established by the standard library", but I don't think this
is actually the right way to do this. Renaming these classes doesn't
make the API feel like native Swift (biggest example is value vs
reference types). What would make them feel like native Swift is writing
a native Swift type with a native Swift API and native Swift conventions
that bridges to/from the obj-c class (e.g. how Swift 3 is gaining the
URL value type).

>  * How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
 
A quick reading of the proposal, as well as reading previous discussions
about this topic.
 
-Kevin Ballard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[James Berry via swift-evolution]

Review of proposal:


https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md

> What is your evaluation of the proposal?
I’m +1 on this.

I believe that it represents a useful cleanup of the Foundation type naming, 
and a maturation of the Swift/Foundation libraries and the integration thereof. 
Yes, changes can be expected in the future, but if we live in perpetual fear of 
what the future might bring then we will advance only slowly toward it. The 
proposal outlines careful thought into how future additional needed transitions 
can be accomplished.


> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes

> Does this proposal fit well with the feel and direction of Swift?
Yes

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
-

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
I’ve followed the discussion carefully and carefully read and assessed the 
proposal.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Philippe Hausler via swift-evolution]

> On May 10, 2016, at 12:48 PM, Philippe Hausler via swift-evolution 
>  wrote:
> 
>> 
>> On May 10, 2016, at 11:11 AM, Ben Rimmington via swift-evolution 
>>  wrote:
>> 
>> > 0086-drop-foundation-ns.md>
>> 
>> +1 to dropping the NS prefix; type names are more readable. However:
>> 
>> * AppKit, CoreData, and TextKit will still use the NS prefix.
>> * Prefixed names (in all frameworks) are more "googleable".
>> * Should deprecated types (e.g. NSMessagePort) keep the prefix?
>> 
>> +1 to using nested enums/options; it will make method signatures shorter.
>> 
>> You could also have a nested RunLoop.Timer class (cf. CFRunLoopTimer) and
>> move your experimental `scheduledTimer` method to the RunLoop class.
>> 
>> Will top-level constants/functions also be nested? For example:
>> 
>> * SE-0033: Import Objective-C Constants as Swift Types
>> * SE-0044: Import as Member
>> 
>> Missing from the "Drop NS prefix" list:
>> 
>> * NSBinarySearchingOptions

More corrections: this will drop it’s NS

>> * NSCopying, NSMutableCopying
> 
> The reasoning behind these keeping NS is that almost all of the mutable 
> copying items have a correlative structural type; e.g. Data, Array, 
> Dictionary, Set etc.
> 
>> * NSDirectoryEnumerator
> 
> NSDirectoryEnumerator is going to be hoisted into 
> FileManager.DirectoryEnumerator (I think the proposal may have missed this 
> one)
> 
>> * NSEnumerationOptions

As will this.

>> * NSEnumerator
> 
> NSEnumerator is used to enumerate the NS collections of references
> 
>> * NSExpression
> 
> This is very tied to KVC and reference collections
> 
>> * NSNull
> 
> Not really applicable in swift since you can have an array of options etc.
> 
>> * NSSecureCoding

This was an oversight and should have it’s prefix dropped as well.

>> * NSSortOptions

NSSortOptions  also will shed it’s prefix

>> 
>> Missing from the "Hoisted types" list:
>> 
>> * NSAffineTransformStruct
> 
> This one is actually being renamed a bit differently; it will be called 
> AffineTransform to the counterpart reference type NSAffineTransform
> 
>> * NSDateComponentsFormatterUnitsStyle
> 
> This is missing from the proposal and should be listed as 
> DateComponentsFormatter.UnitsStyle
> 
>> * NSDateComponentsFormatterZeroFormattingBehavior
> 
> This is missing from the proposal and should be listed as 
> DateComponentsFormatter.ZeroFormattingBehavior
> 
>> * NSRoundingMode
> 
> This is missing from the proposal and should be listed as Decimal.RoundingMode
> 
>> 
>> -- Ben
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> The others I need to follow up on with Tony to determine if they need better 
> refinements.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Philippe Hausler via swift-evolution]

> On May 10, 2016, at 11:11 AM, Ben Rimmington via swift-evolution 
>  wrote:
> 
>  0086-drop-foundation-ns.md>
> 
> +1 to dropping the NS prefix; type names are more readable. However:
> 
> * AppKit, CoreData, and TextKit will still use the NS prefix.
> * Prefixed names (in all frameworks) are more "googleable".
> * Should deprecated types (e.g. NSMessagePort) keep the prefix?
> 
> +1 to using nested enums/options; it will make method signatures shorter.
> 
> You could also have a nested RunLoop.Timer class (cf. CFRunLoopTimer) and
> move your experimental `scheduledTimer` method to the RunLoop class.
> 
> Will top-level constants/functions also be nested? For example:
> 
> * SE-0033: Import Objective-C Constants as Swift Types
> * SE-0044: Import as Member
> 
> Missing from the "Drop NS prefix" list:
> 
> * NSBinarySearchingOptions
> * NSCopying, NSMutableCopying

The reasoning behind these keeping NS is that almost all of the mutable copying 
items have a correlative structural type; e.g. Data, Array, Dictionary, Set etc.

> * NSDirectoryEnumerator

NSDirectoryEnumerator is going to be hoisted into 
FileManager.DirectoryEnumerator (I think the proposal may have missed this one)

> * NSEnumerationOptions
> * NSEnumerator

NSEnumerator is used to enumerate the NS collections of references

> * NSExpression

This is very tied to KVC and reference collections

> * NSNull

Not really applicable in swift since you can have an array of options etc.

> * NSSecureCoding
> * NSSortOptions
> 
> Missing from the "Hoisted types" list:
> 
> * NSAffineTransformStruct

This one is actually being renamed a bit differently; it will be called 
AffineTransform to the counterpart reference type NSAffineTransform

> * NSDateComponentsFormatterUnitsStyle

This is missing from the proposal and should be listed as 
DateComponentsFormatter.UnitsStyle

> * NSDateComponentsFormatterZeroFormattingBehavior

This is missing from the proposal and should be listed as 
DateComponentsFormatter.ZeroFormattingBehavior

> * NSRoundingMode

This is missing from the proposal and should be listed as Decimal.RoundingMode

> 
> -- Ben
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

The others I need to follow up on with Tony to determine if they need better 
refinements.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Ben Rimmington via swift-evolution]

+1 to dropping the NS prefix; type names are more readable. However:

* AppKit, CoreData, and TextKit will still use the NS prefix.
* Prefixed names (in all frameworks) are more "googleable".
* Should deprecated types (e.g. NSMessagePort) keep the prefix?

+1 to using nested enums/options; it will make method signatures shorter.

You could also have a nested RunLoop.Timer class (cf. CFRunLoopTimer) and
move your experimental `scheduledTimer` method to the RunLoop class.

Will top-level constants/functions also be nested? For example:

* SE-0033: Import Objective-C Constants as Swift Types
* SE-0044: Import as Member

Missing from the "Drop NS prefix" list:

* NSBinarySearchingOptions
* NSCopying, NSMutableCopying
* NSDirectoryEnumerator
* NSEnumerationOptions
* NSEnumerator
* NSExpression
* NSNull
* NSSecureCoding
* NSSortOptions

Missing from the "Hoisted types" list:

* NSAffineTransformStruct
* NSDateComponentsFormatterUnitsStyle
* NSDateComponentsFormatterZeroFormattingBehavior
* NSRoundingMode

-- Ben


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

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Geordie Jay via swift-evolution]

> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution 
> >:
> 
> 
>> What is your evaluation of the proposal?
> Personally I’m a -1; I’d prefer to see the NS prefix remain on types that 
> have been translated automatically with minimal human interaction, in favour 
> of dropping the prefix for types that have received more attention to 
> establish a Swift-ier style, but migrating these into a new module instead.

I strongly agree with keeping NS prefix on API that has not been ‘Swiftified'. 
First step, achieve functional equivalence with Darwin APIs. Second step, 
systematically improve Foundation to the point where it feels like this 
fundamental part of the language is as easy to use and idiomatic as the 
standard library itself. At that point I’d be very much for dropping the 
prefixes.

> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Since it’s a basic API that most developers will be interacting with then 
> yes, even though the change is fairly minor, it definitely bears 
> consideration.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at the 
> same time this is why I’d like to keep the current convention for existing 
> (unchanged) types, as it makes it much clearer that these are things that 
> weren’t originally designed for Swift and thus won’t behave quite as you 
> might expect.

Completely agree

> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> I’ve worked in languages where libraries had different styles of 
> name-spacing, and while it was annoying to have a mixture, I think it was 
> fine, especially for libraries that are older, as the prefix name-spacing 
> style makes it absolutely clear that this is an older API.
> 

Yes, we should be clear this is an older API, also to add motivation on 
introducing a more modern one (even if at first it just wraps Foundation with a 
more Swift-like API)

>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> 
> Quick read of the proposal, kept an eye on the discussion leading up to it 
> though.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Geordie Jay via swift-evolution]

> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution 
> >:
> 
> 
>> What is your evaluation of the proposal?
> Personally I’m a -1; I’d prefer to see the NS prefix remain on types that 
> have been translated automatically with minimal human interaction, in favour 
> of dropping the prefix for types that have received more attention to 
> establish a Swift-ier style, but migrating these into a new module instead.

I strongly agree with keeping NS prefix on API that has not been ‘Swiftified'. 
First step, achieve functional equivalence with Darwin APIs. Second step, 
systematically improve Foundation to the point where it feels like this 
fundamental part of the language is as easy to use and idiomatic as the 
standard library itself. At that point I’d be very much for dropping the 
prefixes.

> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Since it’s a basic API that most developers will be interacting with then 
> yes, even though the change is fairly minor, it definitely bears 
> consideration.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at the 
> same time this is why I’d like to keep the current convention for existing 
> (unchanged) types, as it makes it much clearer that these are things that 
> weren’t originally designed for Swift and thus won’t behave quite as you 
> might expect.

Completely agree

> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> I’ve worked in languages where libraries had different styles of 
> name-spacing, and while it was annoying to have a mixture, I think it was 
> fine, especially for libraries that are older, as the prefix name-spacing 
> style makes it absolutely clear that this is an older API.
> 

Yes, we should be clear this is an older API, also to add motivation on 
introducing a more modern one (even if at first it just wraps Foundation with a 
more Swift-like API)

>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> 
> Quick read of the proposal, kept an eye on the discussion leading up to it 
> though.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Geordie Jay via swift-evolution]

> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution 
> >:
> 
> 
>> What is your evaluation of the proposal?
> Personally I’m a -1; I’d prefer to see the NS prefix remain on types that 
> have been translated automatically with minimal human interaction, in favour 
> of dropping the prefix for types that have received more attention to 
> establish a Swift-ier style, but migrating these into a new module instead.

I strongly agree with keeping NS prefix on API that has not been ‘Swiftified'. 
First step, achieve functional equivalence with Darwin APIs. Second step, 
systematically improve Foundation to the point where it feels like this 
fundamental part of the language is as easy to use and idiomatic as the 
standard library itself. At that point I’d be very much for dropping the 
prefixes.

> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Since it’s a basic API that most developers will be interacting with then 
> yes, even though the change is fairly minor, it definitely bears 
> consideration.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at the 
> same time this is why I’d like to keep the current convention for existing 
> (unchanged) types, as it makes it much clearer that these are things that 
> weren’t originally designed for Swift and thus won’t behave quite as you 
> might expect.

Completely agree

> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> I’ve worked in languages where libraries had different styles of 
> name-spacing, and while it was annoying to have a mixture, I think it was 
> fine, especially for libraries that are older, as the prefix name-spacing 
> style makes it absolutely clear that this is an older API.
> 

Yes, we should be clear this is an older API, also to add motivation on 
introducing a more modern one (even if at first it just wraps Foundation with a 
more Swift-like API)

>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> 
> Quick read of the proposal, kept an eye on the discussion leading up to it 
> though.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Haravikk via swift-evolution]

> What is your evaluation of the proposal?
Personally I’m a -1; I’d prefer to see the NS prefix remain on types that have 
been translated automatically with minimal human interaction, in favour of 
dropping the prefix for types that have received more attention to establish a 
Swift-ier style, but migrating these into a new module instead.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Since it’s a basic API that most developers will be interacting with then yes, 
even though the change is fairly minor, it definitely bears consideration.

> Does this proposal fit well with the feel and direction of Swift?
Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at the 
same time this is why I’d like to keep the current convention for existing 
(unchanged) types, as it makes it much clearer that these are things that 
weren’t originally designed for Swift and thus won’t behave quite as you might 
expect.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I’ve worked in languages where libraries had different styles of name-spacing, 
and while it was annoying to have a mixture, I think it was fine, especially 
for libraries that are older, as the prefix name-spacing style makes it 
absolutely clear that this is an older API.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Quick read of the proposal, kept an eye on the discussion leading up to it 
though.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Charles Srstka via swift-evolution]

On May 9, 2016, at 7:38 PM, Rod Brown via swift-evolution 
 wrote:
> 
> I am uncertain about the NSCoding proposition as it is not a generic concept 
> that is platform agnostic. It is a baked in, Objective-C, Apple-only paradigm 
> that seems to me should retain it’s NS prefix.

Plus, NSCoding has a *lot* of legacy cruft associated with it that we would do 
well to jettison with a brand-new coding protocol, IMO.

Charles

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

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Rod Brown via swift-evolution]

> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md
>  
> 
> Reply text
> 
>> What is your evaluation of the proposal?
> +1 to all except renaming classes that are planned in the future to become 
> value types, and the NSCoding issue.
> 
> I agree with Brent that I am unconvinced we should take off NS from those we 
> have identified as future value types. Classes we highly suspect should 
> become value types should retain their NS prefix at this time, as preparation 
> to avoid the mess that would be to come from reverting, deprecating etc. Just 
> because we don’t have enough time to get these value types sorted right away 
> doesn’t mean we should shoot ourselves in the foot by changing things we’ve 
> already identified as high potential for Value Type Transition. If we 
> identify other types later on that should move to value semantics, these 
> strategies would work, but I wonder why deliberately create a headache for 
> ourselves?
> 
> I am uncertain about the NSCoding proposition as it is not a generic concept 
> that is platform agnostic. It is a baked in, Objective-C, Apple-only paradigm 
> that seems to me should retain it’s NS prefix.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> It’s important to get Swift Foundation and Objective-C Foundation heading in 
> the right direction, and to provide for more Swiftification in Foundation in 
> the future, so I think this is significant enough.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> Yes and no. I agree with Brent that dropping NS on high-probability value 
> types is not a wise move, and will slow down value type adoption. It seems 
> easier to deprecate the name with NS at a later date if it is determined it 
> must stay a reference type, than it would be trying to go the other way when 
> we decide to move something to value type.
> 
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> N/A
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> Read through the proposal, and have followed the preceding discussions 
> regarding value type adoption and the name transition.
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[David Hart via swift-evolution]

> What is your evaluation of the proposal?
+1 I already gave my opinion in the original discussion but I’ll summarise it 
here. I understand the fears that this proposal may inhibit us in the future 
from making the modifications that Foundation needs to make it feel more 
Swifty. But I think that those fears are maybe exaggerated and that this 
proposal is the first step in the right direction.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
This could mean the difference between a good and a great adoption of 
corelibs-foundation, so I think it definitely is significant enough.

> Does this proposal fit well with the feel and direction of Swift?
Definitely.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Not applicable to this proposal.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

I read the proposal in detail and followed the heated debate around the pitch :)

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