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 <[email protected]> wrote: > > This sounds like a good idea. > > -Matt > >> On May 10, 2016, at 03:43, Geordie Jay via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution >>> <[email protected] <mailto:[email protected]>>: >>> >>> >>>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
