Hi Pushkar, > On Nov 29, 2016, at 4:12 AM, Pushkar N Kulkarni via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > Hi there, > > I am curious about how an autoupdating type property like `NSTimeZone.local` > could be implemented, given that it is a value (the type is TimeZone). The > requirement essentially is that if the default timezone is changed, the > change should reflect in all copies of this value. > > import Foundation > > > > let local = NSTimeZone.local > > let local1 = local > > print(local) //prints the default TimeZone > > print(local1) //prints the default TimeZone > > > > let t = TimeZone(identifier: "America/Chicago")! > > NSTimeZone.default = t > > > > print(local) //prints "America/Chicago (autoupdatingCurrent) > > print(local1) //prints "America/Chicago (autoupdatingCurrent) > > > > What makes it complicated is that TimeZone is a value type. I hope I am not > missing something fundamental here! > > Any ideas or information will be highly appreciated. Thanks!
You’re not missing anything fundamental. We considered this case very carefully before proposing these types as value types. I agree that it’s on the borderline, but in the end having it as a value type was too valuable (no pun intended). What we decided is essentially this: the value of the time zone is not its identifier. Instead, abstract it one level. That means that “Autoupdating” can be the actual value. Like an open enumeration. Now, nothing in the value type contract says that you cannot have computed properties on a value type. Also, value types are not necessarily “pure”, in the sense that they ignore all external input. What this means for time zone is that its identifier can change depending on user preferences, if its value is “autoupdating". If you set its value to a specific time zone instead, then it does not have the value of “autoupdating" and its computed properties do not behave that way. I reflected this contract in the == method as well. Autoupdating time zones are equal to other autoupdating time zones. However, the autoupdating time zone is not equal to America/Chicago, even if the current time zone is America/Chicago. let la = TimeZone(identifier: "America/Los_Angeles”) // America/Los_Angeles (current) let tz = TimeZone.autoupdatingCurrent // America/Los_Angeles (autoupdatingCurrent) la == tz // false let tz2 = TimeZone.autoupdatingCurrent // America/Los_Angeles (autoupdatingCurrent) tz == tz2 // true In the case of Calendar, if you mutate it then it is no longer autoupdating — you have changed its value. I’m sure reasonable people could disagree on the direction we chose here, and if we were reinventing the world from scratch I probably would not have added this complication to the API. However, the existing autoupdating concept is used pervasively and I needed a way to fit it into the new system. - Tony > > Pushkar N Kulkarni, > IBM Runtimes > > Simplicity is prerequisite for reliability - Edsger W. Dijkstra > > > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
