Autoupdating type properties

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!

Pushkar N Kulkarni,

IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra

Hi Pushkar,

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

···

On Nov 29, 2016, at 4:12 AM, Pushkar N Kulkarni via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

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

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.

Pushkar N Kulkarni,

IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra

  1. Existing copies of 'NSTimezone.local' (referring to the example in my question) will also not reflect the change.

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
···

On Nov 29, 2016, at 4:12 AM, Pushkar N Kulkarni via swift-corelibs-dev swift-corelibs-dev@swift.org wrote:

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

To: Pushkar N Kulkarni/India/IBM@IBMIN
From: Tony Parker
Sent by: anthony.parker@apple.com
Date: 11/30/2016 01:39PM
Cc: swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Autoupdating type properties

Hi Pushkar,

-----anthony.parker@apple.com wrote: -----

Hi Pushkar,

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.

···

On Nov 30, 2016, at 6:39 AM, Pushkar N Kulkarni <pushkar.nk@in.ibm.com> wrote:

Pushkar N Kulkarni,
IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra

-----anthony.parker@apple.com <mailto:-----anthony.parker@apple.com> wrote: -----
To: Pushkar N Kulkarni/India/IBM@IBMIN
From: Tony Parker
Sent by: anthony.parker@apple.com <mailto:anthony.parker@apple.com>
Date: 11/30/2016 01:39PM
Cc: swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@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@swift.org <mailto: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 <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev