[swift-corelibs-dev] Autoupdating type properties

[Tony Parker]

Hi Pushkar,

> On Nov 30, 2016, at 6:39 AM, Pushkar N Kulkarni <pushkar.nk at in.ibm.com> wrote:
> 
> Thanks Tony, for the detailed explanation! 
> 
>  I think I need a bit more clarification though :)
> 
> >>> 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.
> 
> Please correct me if I am wrong in deriving these from the above:
> 1. `NSTimezone.local` will be a computed type property, which when invoked can return different values (based on user preferences - an external factor) at different points in application's lifetime.
> 2. If NSTimezone.default is explicitly set to a time zone, NSTimezone.local will not reflect that change.
> 3. Existing copies of 'NSTimezone.local' (referring to the example in my question) will also not reflect the change.
> 

Swift clients should really use struct TimeZone instead of class NSTimeZone. I updated struct TimeZone’s naming and static functions to be a lot more clear:

    /// The time zone currently used by the system.
    public static var current : TimeZone


    /// The time zone currently used by the system, automatically updating to the user's current preference.
    ///
    /// If this time zone is mutated, then it no longer tracks the application time zone.
    ///
    /// The autoupdating time zone only compares equal to itself.
    public static var autoupdatingCurrent : TimeZone

The ‘current’ struct TimeZone is the ‘system’ NSTimeZone. The ‘autoupdatingCurrent’ struct TimeZone is the ‘autoupdatingCurrent’ NSTimeZone. The ‘default’ NSTimeZone is an awful pattern that nobody should use, because it’s likely to be an unexpected value*. I did not include it in struct TimeZone.

The result of calling ‘current’ will change depending on external factors (user prefs), but the result from calling it will stay whatever value it was when you retrieved it.

The result of calling ‘autoupdatingCurrent’ will always be an autoupdating time zone, which will reflect user preferences on its properties when called.

Hope that helps,
- Tony

* details: Anyone can set the default time zone, but once it’s retrieved using that class method then your copy no longer updates. So you may think you’re setting the default time zone for your app, but in reality if some piece of code sets it after some other piece of code gets it, you’re just using two different time zones in your app. All of the problems of shared global state.

> 
> Pushkar N Kulkarni,
> IBM Runtimes
> 
> Simplicity is prerequisite for reliability - Edsger W. Dijkstra
> 
> 
> 
> -----anthony.parker at apple.com <mailto:-----anthony.parker at apple.com> wrote: -----
> To: Pushkar N Kulkarni/India/IBM at IBMIN
> From: Tony Parker 
> Sent by: anthony.parker at apple.com <mailto:anthony.parker at apple.com>
> Date: 11/30/2016 01:39PM
> Cc: swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>>
> Subject: Re: [swift-corelibs-dev] Autoupdating type properties
> 
> Hi Pushkar,
> 
>> On Nov 29, 2016, at 4:12 AM, Pushkar N Kulkarni via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at 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 at swift.org <mailto:swift-corelibs-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20161130/ee50a5b5/attachment.html>