Hi Riley, > On Apr 22, 2016, at 1:34 PM, Riley Testut <[email protected]> wrote: > > Very happy to see this proposal; felt strange that for a language so focused > on value-types an entire framework open sourced with the language was > composed entirely of reference-types (albeit for obvious reasons). So +1 for > that. > > One particular section that caught my interest was this: >> The most obvious drawback to using a struct is that the type can no longer >> be subclassed. At first glance, this would seem to prevent the customization >> of behavior of these types. However, by publicizing the reference type and >> providing a mechanism to wrap it (mySubclassInstance as ValueType), we >> enable subclasses to provide customized behavior. > > I'm incredibly biased, but I recently proposed and submitted a pull request > that would introduce "factory initializers" to the language > (https://github.com/apple/swift-evolution/pull/247 > <https://github.com/apple/swift-evolution/pull/247>). The full proposal has > more info, but essentially factory initializers would allow for directly > returning initialized types from designated factory initializers, similar to > how initializers are implemented in Objective-C. > > Anyway, I feel the Factory Initializer proposal would work very well with > this Foundation proposal. While I believe the current suggestion of casting > the reference type as the value type works well, I don't believe it is > necessarily the client of the API's job to use it; I believe it would make > far more sense for there to be an extension adding additional factory > initializers to the class, which would determine the underlying reference > type to use based on the input parameters. > > For example, here is the example of using a custom subclass for the Data type > mentioned in this Foundation proposal: >> /// Create a Data with a custom backing reference type. >> class MyData : NSData { } >> let dataReference = MyData() >> let dataValue = dataReference as Data // dataValue copies dataReference > > I personally would rather see something akin to this: > > public extension Data { > factory init(inputData: ...) > { > if ... { > // Return subclass best suited for storing this > particular input data > return MyData(inputData) as Data > } > else { > let data = NSData() > > /* OMITTED: add hypothetical inputData to NSData > depending on what it is */ > > return data > } > > This means the client of the API never has to worry about which subclass is > best suited for them; everything would "just work". This also better mimics > the existing class cluster pattern in Foundation, which might help with this > transition should my proposal be accepted. > > Regardless though, very happy to see this being pushed forward. Just thought > I'd suggest ways to make this proposal (hopefully) easier to both implement > and use :)
Thanks for your feedback. For what it’s worth, I’m fully in support of your factory type proposal as well. I think we need it in order to finish a complete implementation of swift-corelibs-foundation, at the very least. We can certainly extend these types to include use of the factory types once we get them into the language. - Tony > > On Apr 22, 2016, at 12:52 PM, Tony Parker via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> Hi David, >> >>> On Apr 22, 2016, at 12:13 PM, David Waite <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Amazing, I am really looking forward to this feature! >>> >>> Comments: >>> >>> - For Locale and Calendar, one possible Swift layout would be to synthesize >>> a protocol and to use that to represent bridged API. You could then bridge >>> inbound to either the immutable value type or the dynamic class-based type. >>> On the swift side, these are constructed as two distinct types. >> >> That’s an interesting approach, I’ll consider that for these. >> >>> >>> - For any of these types, are there improvements (similar to String) which >>> would be worth making before exposing ’the’ Swift type and API? The ones >>> I’m specifically worried about are Date and URL, since I’ve seen so many >>> standard language time and networking API show their age over time. >>> >>> -DW >> >> We’re absolutely going to be making Swift-specific improvements to many of >> these types. I think the resulting API is better in many ways. For example, >> on URL the main improvement is that the resource values dictionary is now >> struct type with a lot of strongly-typed properties. It’s still got a lot of >> optionals because of the way that the underlying fetch works, but it’s >> better. Date gains mutating methods along with support for operators like += >> and < >. >> >> One of the guiding principles of our effort was evolution over revolution. >> Foundation is obviously used in tons and tons of API. We want to maintain >> conceptual compatibility with the entire OS X / iOS / watchOS / tvOS SDK >> when it is imported into Swift. Hopefully this also means that converting >> from reference to value types in your own uses of these API does not require >> a complete rethink of how you use them, but still provide the benefits >> outlined in the proposal. We’ll continue to iterate and improve over time. >> >> Thanks, >> >> - Tony >> >>> >>>> On Apr 22, 2016, at 11:18 AM, Tony Parker via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> Dear swift-evolution denizens, >>>> >>>> As you know from our announcement of Swift Open Source and our work on >>>> naming guidelines, one of our goals for Swift 3 is to “drop NS” for >>>> Foundation. We want to to make the cross-platform Foundation API that is >>>> available as part of swift-corelibs feel like it is not tied to just >>>> Darwin targets. We also want to reinforce the idea that new Foundation API >>>> must fit in with the language, standard library, and the rapidly evolving >>>> design patterns we see in the community. >>>> >>>> You challenged us on one part of this plan: some Foundation API just >>>> doesn’t “feel Swifty”, and a large part of the reason why is that it often >>>> does not have the same value type behavior as other Swift types. We took >>>> this feedback seriously, and I would like to share with you the start of >>>> an important journey for some of the most commonly used APIs on all of our >>>> platforms: adopting value semantics for key Foundation types. >>>> >>>> We have been working on this for some time now, and the set of diffs that >>>> result from this change is large. At this point, I am going to focus >>>> effort on an overview of the high level goals and not the individual API >>>> of each new type. In order to focus on delivering something up to our >>>> quality standards, we are intentionally leaving some class types as-is >>>> until a future proposal. If you don’t see your favorite class on the list >>>> — don’t despair. We are going to iterate on this over time. I see this as >>>> the start of the process. >>>> >>>> One process note: we are still trying to figure out the best way to >>>> integrate changes to API that ship as part of the operating system (which >>>> includes Foundation) into the swift-evolution review process. >>>> Swift-evolution is normally focused on changes to functionality in the >>>> compiler or standard library. In general, I don’t expect all new >>>> Foundation API introduced in the Darwin/Objective-C framework to go >>>> through the open source process. However, as we’ve brought up this topic >>>> here before, I felt it was important to bring this particular change to >>>> the swift-evolution list. >>>> >>>> As always I welcome your feedback. >>>> >>>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md >>>> >>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md> >>>> >>>> Thanks, >>>> - Tony >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
