Re: [swift-corelibs-dev] Autoupdating type properties

[Pushkar N Kulkarni via 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.

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

Pushkar N Kulkarni,

IBM Runtimes

Simplicity is prerequisite for reliability - Edsger W. Dijkstra

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

To: Pushkar N Kulkarni/India/IBM@IBMIN
From: Tony Parker
Sent by: anthony.par...@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,

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