Re: [swift-users] extension on UISlider breaks interface builder??

[Jon Shier via swift-users]

In my experience, yes, it started with Xcode 8, though I don’t 
specifically remember extending types I was using in IB in Xcode 7.



Jon

> On Jul 14, 2017, at 11:54 PM, David Baraff  wrote:
> 
>> 
>> On Jul 14, 2017, at 8:53 PM, Jon Shier via swift-users 
>> > wrote:
>> 
>>  Yep, known issue, fixed in Xcode 9 beta 3 according to the release 
>> notes. Hugely annoying, but comment out the extension, connect the outlet, 
>> and comment it back it and should work fine. 
> 
> thank you!  Just to clarify, this isn’t new breakage in xcode 9, but 
> something broken in xcode 8, yes?
> all the more reason to want swift 4 and xcode 9 then...
>> 
>> 
>> Jon
>> 
>>> On Jul 14, 2017, at 11:51 PM, David Baraff via swift-users 
>>>  wrote:
>>> 
>>> TL;DR
>>> Add an extension to UISlider and interface builder in xcode will no longer 
>>> believe it has *any* actions.
>>> Is this a known issue?
>>> 
>>> 
>>> 1. I added a UISlider to a storyboard in xcode.  I right clicked on it, and 
>>> saw the usual set of things, particularly, actions (sent events):
>>> 
>>> 
>>> 
>>> Next, I wrote this:
>>> 
>>> public protocol ModelDataValuedUIControl: class {
>>>   var xxcontrolValue:Any {
>>>   get set
>>>   }
>>> }
>>> 
>>> extension UISlider : ModelDataValuedUIControl {
>>>   public var xxcontrolValue:Any {
>>>   get {
>>>   return self.value
>>>   }
>>> 
>>>   set(newValue) {
>>>   self.value = newValue as! Float
>>>   }
>>>   }
>>> }
>>> 
>>> 
>>> Lo and behold, after compiling, interface builder *hates* sliders, because 
>>> now the rightclick menu looks like this:
>>> 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] extension on UISlider breaks interface builder??

[David Baraff via swift-users]

> On Jul 14, 2017, at 8:53 PM, Jon Shier via swift-users 
>  wrote:
> 
>   Yep, known issue, fixed in Xcode 9 beta 3 according to the release 
> notes. Hugely annoying, but comment out the extension, connect the outlet, 
> and comment it back it and should work fine. 

thank you!  Just to clarify, this isn’t new breakage in xcode 9, but something 
broken in xcode 8, yes?
all the more reason to want swift 4 and xcode 9 then...
> 
> 
> Jon
> 
>> On Jul 14, 2017, at 11:51 PM, David Baraff via swift-users 
>>  wrote:
>> 
>> TL;DR
>> Add an extension to UISlider and interface builder in xcode will no longer 
>> believe it has *any* actions.
>> Is this a known issue?
>> 
>> 
>> 1. I added a UISlider to a storyboard in xcode.  I right clicked on it, and 
>> saw the usual set of things, particularly, actions (sent events):
>> 
>> 
>> 
>> Next, I wrote this:
>> 
>> public protocol ModelDataValuedUIControl: class {
>>var xxcontrolValue:Any {
>>get set
>>}
>> }
>> 
>> extension UISlider : ModelDataValuedUIControl {
>>public var xxcontrolValue:Any {
>>get {
>>return self.value
>>}
>> 
>>set(newValue) {
>>self.value = newValue as! Float
>>}
>>}
>> }
>> 
>> 
>> Lo and behold, after compiling, interface builder *hates* sliders, because 
>> now the rightclick menu looks like this:
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift 4 emulating Decoder behaviour

[Itai Ferber via swift-users]

Hi Joanna,

Your example doesn’t work for a few reasons:

1. You’re getting a compiler error because of the difference between 
the representation of metatypes (`Foo.Type` for some type `Foo`) of 
concrete types (e.g. `String`, `Int`), and protocols (e.g. 
`DefaultValueProvider`). Some of the compiler folks can correct my exact 
use of terminology here, but the essence is this: when you `as?`-cast a 
type to a concrete type (e.g. `type as? String.self`), you’ll get a 
concrete metatype which can be used dynamically as you would a concrete 
type elsewhere. When you `as?`-cast a type to a protocol type (`type as? 
DefaultValueProvider`), however, you get a protocol-constrained metatype 
which is not concrete and cannot be used dynamically as you would 
statically. You can call statically-known protocol methods on the 
metatype (e.g. `(type as! DefaultValueProvider).init()`), but the 
concrete type is not known. You can see this with a small example:


  ```swift
  protocol P {
  init()
  }

  extension Int : P {}

  let type: Any.Type = Int.self
  if let specific = type as? P.Type {
  // type of specific.init() is P, not Int
  print(specific.init())
  }
  ```

  This, then coincides with:

2. The fact that methods generic on types can only take concrete type 
parameters. Protocol metatypes cannot be passed in as you would a 
concrete metatype:


  ```swift
  protocol P {}
  extension Int : P {}

  func foo(_ type: T.Type) {
  print(type)
  }

  let type: Any.Type = Int.self
  foo(type) // cannot invoke 'foo' with an argument list of type 
'(Any.Type)'
  foo(type as! P.Type) // cannot invoke 'foo' with an argument list of 
type '(P.Type)'

  foo(type as! Int.Type) // works just fine
  ```

  Arguments to generic methods _must_ be statically knowable for the 
method to be dispatched; otherwise you’ll get the compiler error that 
you see.


This is also why you can’t `decode(Decodable.self)` or 
`decode(Any.self)` — those are not concrete types.
(On a side note, though, this would never be possible with the 
`Decodable` protocol. We need a concrete type to decode because values 
are otherwise ambiguous. Is `5` an `Int8`, `UInt8`, …, `Int`, `UInt`, 
…, `Int64`, `UInt64`, `Float`, or `Double`? Is `"2017-07-14"` a 
`String` or a `Date`? What would you expect to get for 
`decode(Decodable.self)`?)


— Itai

On 13 Jul 2017, at 11:46, Joanna Carter via swift-users wrote:


Greetings

I notice that, with Swift 4, I can decode an object like this :

	• let retrievedSpot = try decoder.decode(ParkingSpot.self, from: 
retrievedData)


And that will return a ParkingSpot, as expected, into retrievedSpot.

However, I thought I would try the same technique with one of my pet 
projects…


I have a protocol  and an implementing struct :

• public protocol PropertyProtocol
• {
•   static var propertyType: Any.Type { get }
•
•   var untypedValue: Any? { get }
• }
•
	• public struct Property : 
PropertyProtocol

• {
•   public static var propertyType: Any.Type
•   {
• return valueT.self
•   }
•
•   public var untypedValue: Any?
•   {
• return value
•   }
•
•   public var value = valueT()
• }

Now, I want to be able to use a "factory" method to create an instance 
of Property, bound to its parameter type. So, I followed the same 
principal as Decoder :


• struct PropertyFactory
• {
	•   static func createProperty(_ type: T.Type) -> 
PropertyProtocol where T : DefaultValueProvider

•   {
• return type.createProperty()
•   }
• }

DefaultValueProvider is defined as follows and String is extended to 
conform to it :


• public protocol DefaultValueProvider
• {
•   init()
• }
•
• extension String : DefaultValueProvider { }

Now, this works fine if I pass a known type :

• let pproperty = PropertyFactory.createProperty(String.self)

But, if I hold the type to be passed in in an Any.Type or 
DefaultValueProvider.Type variable, then doing this :


• let type: Any.Type = String.self
•
• if let propertyType = type as? DefaultValueProvider.Type
• {
•   let p = PropertyFactory.createProperty(propertyType)
•
•   …

Fails to compile with the message : Cannot invoke 'createProperty' 
with an argument list of type '(DefaultValueProvider.Type)'


Likewise Decoder.decode(…) will not accept storing the type in an 
Any.Type or Decodable.Type variable.


I find this odd and perplexing. Is this a known issue or has nobody 
yet realised that this could be useful ?


Joanna

--
Joanna Carter
Carter Consulting
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Unsubscribe

[Jordan Rose via swift-users]

Oops, thought the mailing list software was supposed to catch this. 
Unsubscribed you, Howard; sorry for the spurious message, everyone else.

-Jordan


> On Jul 14, 2017, at 10:03, Howard Perlman via swift-users 
>  wrote:
> 
> Unsubscribe
> 
> 
> From: "swift-users-requ...@swift.org" 
> To: swift-users@swift.org 
> Sent: Friday, July 14, 2017 12:57 PM
> Subject: swift-users Digest, Vol 20, Issue 13
> 
> Send swift-users mailing list submissions to
> swift-users@swift.org 
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
> or, via email, send a message with subject or body 'help' to
> swift-users-requ...@swift.org 
> 
> You can reach the person managing the list at
> swift-users-ow...@swift.org 
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of swift-users digest..."
> 
> 
> Today's Topics:
> 
>   1. Swift 4 emulating Decoder behaviour (Joanna Carter)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 13 Jul 2017 20:46:20 +0200
> From: Joanna Carter  >
> To: swift-users@swift.org 
> Subject: [swift-users] Swift 4 emulating Decoder behaviour
> Message-ID:
>  >
> Content-Type: text/plain; charset=utf-8
> 
> Greetings
> 
> I notice that, with Swift 4, I can decode an object like this :
> 
> • let retrievedSpot = try decoder.decode(ParkingSpot.self, from: 
> retrievedData)  
> 
> And that will return a ParkingSpot, as expected, into retrievedSpot.
> 
> However, I thought I would try the same technique with one of my pet projects…
> 
> I have a protocol  and an implementing struct :
> 
> • public protocol PropertyProtocol  
> • {  
> •  static var propertyType: Any.Type { get }  
> •  
> •  var untypedValue: Any? { get }  
> • }  
> •  
> • public struct Property : 
> PropertyProtocol  
> • {  
> •  public static var propertyType: Any.Type  
> •  {  
> •return valueT.self  
> •  }  
> •  
> •  public var untypedValue: Any?  
> •  {  
> •return value  
> •  }  
> •  
> •  public var value = valueT()  
> • }  
> 
> Now, I want to be able to use a "factory" method to create an instance of 
> Property, bound to its parameter type. So, I followed the same principal 
> as Decoder :
> 
> • struct PropertyFactory  
> • {  
> •  static func createProperty(_ type: T.Type) -> PropertyProtocol 
> where T : DefaultValueProvider  
> •  {  
> •return type.createProperty()  
> •  }  
> • }  
> 
> DefaultValueProvider is defined as follows and String is extended to conform 
> to it :
> 
> • public protocol DefaultValueProvider  
> • {  
> •  init()  
> • }  
> •  
> • extension String : DefaultValueProvider { }  
> 
> Now, this works fine if I pass a known type :
> 
> • let pproperty = PropertyFactory.createProperty(String.self)  
> 
> But, if I hold the type to be passed in in an Any.Type or 
> DefaultValueProvider.Type variable, then doing this :
> 
> •let type: Any.Type = String.self  
> •  
> •if let propertyType = type as? DefaultValueProvider.Type  
> •{  
> •  let p = PropertyFactory.createProperty(propertyType)  
> •  
> •  …  
> 
> Fails to compile with the message : Cannot invoke 'createProperty' with an 
> argument list of type '(DefaultValueProvider.Type)'
> 
> Likewise Decoder.decode(…) will not accept storing the type in an Any.Type or 
> Decodable.Type variable.
> 
> I find this odd and perplexing. Is this a known issue or has nobody yet 
> realised that this could be useful ?
> 
> Joanna
> 
> --
> Joanna Carter
> Carter Consulting
> 
> --
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
> 
> 
> End of swift-users Digest, Vol 20, Issue 13
> ***
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users