[swift-users] Fwd: Workaround for generics not currently supporting conditional conformance to a protocol

[Howard Lovatt via swift-users]

@Dave,

How do I write that though.

I can't write:

extension Array: Equatable {
static func ==(lhs: Array, rhs: Array) -> Bool {
let size = lhs.count
precondition(rhs.count == size, "The arrays must be the same
length")
for i in 0 ..< size {
if (lhs[i] as! Equatable) != (rhs[i] as! Equatable) {
return false
}
}
return true
}
}

Because I can't cast to an Equatable, because Equatable uses Self.

Am I missing something?

 -- Howard.

  -- Howard.

On 16 November 2016 at 16:35, David Sweeris  wrote:

>
> > On Nov 15, 2016, at 21:39, Howard Lovatt via swift-users <
> swift-users@swift.org> wrote:
> >
> > Hi All,
> >
> > Does anyone have a good workaround for generics not currently supporting
> conditional conformance to a protocol. As stated in the Generics Manifesto
> something like this would be nice:
> >
> >   extension Array: Equatable where Element: Equatable {
> > static func ==(lhs: Array, rhs: Array) -> Bool { ... }
> > }
> >
> > But I would currently write a wrapper, something like:
> >
> > struct ArrayE {
> > var elements: [T]
> > }
> > extension ArrayE: Equatable {
> > static func ==(lhs: ArrayE, rhs: ArrayE) -> Bool { ...  }
> > }
> >
> > This can get unwieldy when there are a lot of conditional protocol
> extensions required, i.e. wrappers round wrappers.
> >
> > Is there a better way?
> >
> > Thanks for any tips,
> >
> >   -- Howard.
> > ___
> > swift-users mailing list
> > swift-users@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-users
>
> Can you make Array conform to Equatable for any T and then in the ==
> function, if T conforms to Equatable loop the Arrays to check if they're
> equal, and if it doesn't conform just return false?
>
> I mean, it's still "wrong", but at least you won't get any false positives.
>
> - Dave Sweeris
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Attempting to call default protocol implementation crashes Playground

[Игорь Никитин via swift-users]

And, as I know, it's not possible to call protocol's implementation in that case

> 16 нояб. 2016 г., в 4:29, Rick Mann via swift-users  
> написал(а):
> 
> Okay. I coudln't find official documentation on this, and I don't currently 
> need to do this, but wanted to fully understand it.
> 
>> On Nov 15, 2016, at 17:27 , zh ao  wrote:
>> 
>> 'Default' implementation in protocol extension is used as fail safe. You 
>> should not consider it like something super class does. If you want it that 
>> way, use class inheritance instead.
>> 
>> Zhaoxin
>> 
>> Get Outlook for iOS
>> 
>> _
>> From: Rick Mann via swift-users 
>> Sent: 星期三, 十一月 16, 2016 07:51
>> Subject: Re: [swift-users] Attempting to call default protocol 
>> implementation crashes Playground
>> To: Dan Loewenherz 
>> Cc: swift-users 
>> 
>> 
>> Well, this is a standard protocol default implementation. I was 
>> experimenting to see if it was possible to call the default implementation 
>> after providing a concrete implementation.
>> 
>>> On Nov 15, 2016, at 14:47 , Dan Loewenherz  wrote:
>>> 
>>> What are you trying to accomplish here, more concretely?
>>> 
>>> My first thought is that you shouldn't implement the same function in both 
>>> a protocol extension and a conforming class. Why not just give them 
>>> different names and call the function from within the extension instead of 
>>> from the class? E.g.
>>> 
>>> protocol FooPro {
>>> func _fooFunc()
>>> }
>>> 
>>> extension FooPro {
>>> func fooFunc() {
>>> print("fooFunc default")
>>> _fooFunc()
>>> }
>>> }
>>> 
>>> class FooClass: FooPro {
>>> func _fooFunc() {
>>> print("fooFunc FooClass")
>>> }
>>> }
>>> 
>>> let fc = FooClass()
>>> fc.fooFunc()
>>> 
>>> Dan
>>> 
>>> On Tue, Nov 15, 2016 at 4:28 PM, Rick Mann via swift-users 
>>>  wrote:
>>> The following gives Xcode 8.1 a very hard time. Eventually I get a Bad 
>>> Access on the last line. I'm guessing it's a recursive call. Is there any 
>>> way to call the default implementation from a "real" implementation?
>>> 
>>> protocol FooPro
>>> {
>>> func fooFunc()
>>> }
>>> 
>>> extension FooPro
>>> {
>>> func
>>> fooFunc()
>>> {
>>> print("fooFunc default")
>>> }
>>> }
>>> 
>>> class FooClass : FooPro
>>> {
>>> func
>>> fooFunc()
>>> {
>>> (self as FooPro).fooFunc()
>>> print("fooFunc FooClass")
>>> }
>>> }
>>> 
>>> let fc: FooPro = FooClass()
>>> fc.fooFunc()
>>> 
>>> 
>>> Thanks!
>>> 
>>> 
>>> --
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>> 
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>> 
>> 
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> 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] Attempting to call default protocol implementation crashes Playground

[Игорь Никитин via swift-users]

And, as I know, it's not possible to call protocol's implementation in that case


> 16 нояб. 2016 г., в 9:09, Игорь Никитин via swift-users 
>  написал(а):
> 
> Right, it’s a recursion, because this 
> 
> (self as FooPro).fooFunc()
> 
> Will call FooClass’s  method implementation
> 
> You can read more about dispatch rules here: 
> https://medium.com/ios-os-x-development/swift-protocol-extension-method-dispatch-6a6bf270ba94#.hkh1rc56p
> 
> 
> 
>> 16 нояб. 2016 г., в 4:29, Rick Mann via swift-users  
>> написал(а):
>> 
>> Okay. I coudln't find official documentation on this, and I don't currently 
>> need to do this, but wanted to fully understand it.
>> 
>>> On Nov 15, 2016, at 17:27 , zh ao  wrote:
>>> 
>>> 'Default' implementation in protocol extension is used as fail safe. You 
>>> should not consider it like something super class does. If you want it that 
>>> way, use class inheritance instead.
>>> 
>>> Zhaoxin
>>> 
>>> Get Outlook for iOS
>>> 
>>> _
>>> From: Rick Mann via swift-users 
>>> Sent: 星期三, 十一月 16, 2016 07:51
>>> Subject: Re: [swift-users] Attempting to call default protocol 
>>> implementation crashes Playground
>>> To: Dan Loewenherz 
>>> Cc: swift-users 
>>> 
>>> 
>>> Well, this is a standard protocol default implementation. I was 
>>> experimenting to see if it was possible to call the default implementation 
>>> after providing a concrete implementation.
>>> 
 On Nov 15, 2016, at 14:47 , Dan Loewenherz  wrote:
 
 What are you trying to accomplish here, more concretely?
 
 My first thought is that you shouldn't implement the same function in both 
 a protocol extension and a conforming class. Why not just give them 
 different names and call the function from within the extension instead of 
 from the class? E.g.
 
 protocol FooPro {
 func _fooFunc()
 }
 
 extension FooPro {
 func fooFunc() {
 print("fooFunc default")
 _fooFunc()
 }
 }
 
 class FooClass: FooPro {
 func _fooFunc() {
 print("fooFunc FooClass")
 }
 }
 
 let fc = FooClass()
 fc.fooFunc()
 
 Dan
 
 On Tue, Nov 15, 2016 at 4:28 PM, Rick Mann via swift-users 
  wrote:
 The following gives Xcode 8.1 a very hard time. Eventually I get a Bad 
 Access on the last line. I'm guessing it's a recursive call. Is there any 
 way to call the default implementation from a "real" implementation?
 
 protocol FooPro
 {
 func fooFunc()
 }
 
 extension FooPro
 {
 func
 fooFunc()
 {
 print("fooFunc default")
 }
 }
 
 class FooClass : FooPro
 {
 func
 fooFunc()
 {
 (self as FooPro).fooFunc()
 print("fooFunc FooClass")
 }
 }
 
 let fc: FooPro = FooClass()
 fc.fooFunc()
 
 
 Thanks!
 
 
 --
 Rick Mann
 rm...@latencyzero.com
 
 
 ___
 swift-users mailing list
 swift-users@swift.org
 https://lists.swift.org/mailman/listinfo/swift-users
 
>>> 
>>> 
>>> -- 
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>> 
>>> 
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> ___
>> 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] Attempting to call default protocol implementation crashes Playground

[Игорь Никитин via swift-users]

Right, it’s a recursion, because this 

(self as FooPro).fooFunc()

Will call FooClass’s  method implementation

You can read more about dispatch rules here: 
https://medium.com/ios-os-x-development/swift-protocol-extension-method-dispatch-6a6bf270ba94#.hkh1rc56p
 




> 16 нояб. 2016 г., в 4:29, Rick Mann via swift-users  
> написал(а):
> 
> Okay. I coudln't find official documentation on this, and I don't currently 
> need to do this, but wanted to fully understand it.
> 
>> On Nov 15, 2016, at 17:27 , zh ao  wrote:
>> 
>> 'Default' implementation in protocol extension is used as fail safe. You 
>> should not consider it like something super class does. If you want it that 
>> way, use class inheritance instead.
>> 
>> Zhaoxin
>> 
>> Get Outlook for iOS
>> 
>> _
>> From: Rick Mann via swift-users 
>> Sent: 星期三, 十一月 16, 2016 07:51
>> Subject: Re: [swift-users] Attempting to call default protocol 
>> implementation crashes Playground
>> To: Dan Loewenherz 
>> Cc: swift-users 
>> 
>> 
>> Well, this is a standard protocol default implementation. I was 
>> experimenting to see if it was possible to call the default implementation 
>> after providing a concrete implementation.
>> 
>>> On Nov 15, 2016, at 14:47 , Dan Loewenherz  wrote:
>>> 
>>> What are you trying to accomplish here, more concretely?
>>> 
>>> My first thought is that you shouldn't implement the same function in both 
>>> a protocol extension and a conforming class. Why not just give them 
>>> different names and call the function from within the extension instead of 
>>> from the class? E.g.
>>> 
>>> protocol FooPro {
>>> func _fooFunc()
>>> }
>>> 
>>> extension FooPro {
>>> func fooFunc() {
>>> print("fooFunc default")
>>> _fooFunc()
>>> }
>>> }
>>> 
>>> class FooClass: FooPro {
>>> func _fooFunc() {
>>> print("fooFunc FooClass")
>>> }
>>> }
>>> 
>>> let fc = FooClass()
>>> fc.fooFunc()
>>> 
>>> Dan
>>> 
>>> On Tue, Nov 15, 2016 at 4:28 PM, Rick Mann via swift-users 
>>>  wrote:
>>> The following gives Xcode 8.1 a very hard time. Eventually I get a Bad 
>>> Access on the last line. I'm guessing it's a recursive call. Is there any 
>>> way to call the default implementation from a "real" implementation?
>>> 
>>> protocol FooPro
>>> {
>>> func fooFunc()
>>> }
>>> 
>>> extension FooPro
>>> {
>>> func
>>> fooFunc()
>>> {
>>> print("fooFunc default")
>>> }
>>> }
>>> 
>>> class FooClass : FooPro
>>> {
>>> func
>>> fooFunc()
>>> {
>>> (self as FooPro).fooFunc()
>>> print("fooFunc FooClass")
>>> }
>>> }
>>> 
>>> let fc: FooPro = FooClass()
>>> fc.fooFunc()
>>> 
>>> 
>>> Thanks!
>>> 
>>> 
>>> --
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>> 
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>> 
>> 
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com 
> 
> 
> ___
> 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] Workaround for generics not currently supporting conditional conformance to a protocol

[Howard Lovatt via swift-users]

Hi All,

Does anyone have a good workaround for generics not currently supporting
conditional conformance to a protocol. As stated in the Generics Manifesto
something like this would be nice:

  extension Array: Equatable where Element: Equatable {
static func ==(lhs: Array, rhs: Array) -> Bool { ... }
}

But I would currently write a wrapper, something like:

struct ArrayE {
var elements: [T]
}
extension ArrayE: Equatable {
static func ==(lhs: ArrayE, rhs: ArrayE) -> Bool { ...  }
}

This can get unwieldy when there are a lot of conditional protocol
extensions required, i.e. wrappers round wrappers.

Is there a better way?

Thanks for any tips,

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

Re: [swift-users] Attempting to call default protocol implementation crashes Playground

[Rick Mann via swift-users]

Okay. I coudln't find official documentation on this, and I don't currently 
need to do this, but wanted to fully understand it.

> On Nov 15, 2016, at 17:27 , zh ao  wrote:
> 
> 'Default' implementation in protocol extension is used as fail safe. You 
> should not consider it like something super class does. If you want it that 
> way, use class inheritance instead.
> 
> Zhaoxin
> 
> Get Outlook for iOS
> 
> _
> From: Rick Mann via swift-users 
> Sent: 星期三, 十一月 16, 2016 07:51
> Subject: Re: [swift-users] Attempting to call default protocol implementation 
> crashes Playground
> To: Dan Loewenherz 
> Cc: swift-users 
> 
> 
> Well, this is a standard protocol default implementation. I was experimenting 
> to see if it was possible to call the default implementation after providing 
> a concrete implementation.
> 
> > On Nov 15, 2016, at 14:47 , Dan Loewenherz  wrote:
> > 
> > What are you trying to accomplish here, more concretely?
> > 
> > My first thought is that you shouldn't implement the same function in both 
> > a protocol extension and a conforming class. Why not just give them 
> > different names and call the function from within the extension instead of 
> > from the class? E.g.
> > 
> > protocol FooPro {
> > func _fooFunc()
> > }
> > 
> > extension FooPro {
> > func fooFunc() {
> > print("fooFunc default")
> > _fooFunc()
> > }
> > }
> > 
> > class FooClass: FooPro {
> > func _fooFunc() {
> > print("fooFunc FooClass")
> > }
> > }
> > 
> > let fc = FooClass()
> > fc.fooFunc()
> > 
> > Dan
> > 
> > On Tue, Nov 15, 2016 at 4:28 PM, Rick Mann via swift-users 
> >  wrote:
> > The following gives Xcode 8.1 a very hard time. Eventually I get a Bad 
> > Access on the last line. I'm guessing it's a recursive call. Is there any 
> > way to call the default implementation from a "real" implementation?
> > 
> > protocol FooPro
> > {
> > func fooFunc()
> > }
> > 
> > extension FooPro
> > {
> > func
> > fooFunc()
> > {
> > print("fooFunc default")
> > }
> > }
> > 
> > class FooClass : FooPro
> > {
> > func
> > fooFunc()
> > {
> > (self as FooPro).fooFunc()
> > print("fooFunc FooClass")
> > }
> > }
> > 
> > let fc: FooPro = FooClass()
> > fc.fooFunc()
> > 
> > 
> > Thanks!
> > 
> > 
> > --
> > Rick Mann
> > rm...@latencyzero.com
> > 
> > 
> > ___
> > swift-users mailing list
> > swift-users@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-users
> > 
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
> 
> 


-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-users] Attempting to call default protocol implementation crashes Playground

[Rick Mann via swift-users]

Well, this is a standard protocol default implementation. I was experimenting 
to see if it was possible to call the default implementation after providing a 
concrete implementation.

> On Nov 15, 2016, at 14:47 , Dan Loewenherz  wrote:
> 
> What are you trying to accomplish here, more concretely?
> 
> My first thought is that you shouldn't implement the same function in both a 
> protocol extension and a conforming class. Why not just give them different 
> names and call the function from within the extension instead of from the 
> class? E.g.
> 
> protocol FooPro {
> func _fooFunc()
> }
> 
> extension FooPro {
> func fooFunc() {
> print("fooFunc default")
> _fooFunc()
> }
> }
> 
> class FooClass: FooPro {
> func _fooFunc() {
> print("fooFunc FooClass")
> }
> }
> 
> let fc = FooClass()
> fc.fooFunc()
> 
> Dan
> 
> On Tue, Nov 15, 2016 at 4:28 PM, Rick Mann via swift-users 
>  wrote:
> The following gives Xcode 8.1 a very hard time. Eventually I get a Bad Access 
> on the last line. I'm guessing it's a recursive call. Is there any way to 
> call the default implementation from a "real" implementation?
> 
> protocol FooPro
> {
> func fooFunc()
> }
> 
> extension FooPro
> {
> func
> fooFunc()
> {
> print("fooFunc default")
> }
> }
> 
> class FooClass : FooPro
> {
> func
> fooFunc()
> {
> (self as FooPro).fooFunc()
> print("fooFunc FooClass")
> }
> }
> 
> let fc: FooPro = FooClass()
> fc.fooFunc()
> 
> 
> Thanks!
> 
> 
> --
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
> 


-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-users] Reflection in Swift 3?

[Rick Mann via swift-users]

> On Nov 15, 2016, at 05:24 , Jeremy Pereira  
> wrote:
> 
> 
>> On 15 Nov 2016, at 10:33, Rick Mann  wrote:
>> 
>> Well, that's not really any different than a switch statement, in that it 
>> has to be maintained.
> 
> Yes, but I would argue that it is a good thing because you need to do some 
> validation before you instantiate the class anyway.
> 
> Furthermore, it gives you more flexibility in terms of initialisation because 
> the closure can invoke any initialiser regardless of parameters and can do 
> other processing as well.

Yeah, but that's not the flexibility I need. And with good 
reflection/introspection, I can do all the validation I need dynamically. In an 
ideal world, I could do something like this:

let pathRenderers = classesThatImplement(protocol: Renderer)
for pr in pathRenderers {
for ini in pr.initializers {
if ini.has(signature: (Path))
{
let renderer = pr.instantiate(aPath)
return
}
}
}

Obviously more complicated than this, but you get the idea.

> 
>> 
>>> On Nov 15, 2016, at 01:50 , Jeremy Pereira 
>>>  wrote:
>>> 
>>> Perhaps I’m missing something here, but why not use a map?
>>> 
>>>  let factoryMap = [ String : () -> SuperClassOrCommonProtocol ] = [ 
>>> “MySubClass" : { return MySubClass() }, … ]
>>> 
>>>  …
>>> 
>>>  guard let factoryMethod = factoryMap[theClassName] else { /* error */ }
>>>  return factoryMethod()
>>> 
>>> This is an approach I always ended up taking in Objective-C anyway, 
>>> because, if you don’t know what’s in the string, you need to validate it 
>>> (imagine if the user of your app finds out that they can cause you to 
>>> instantiate any arbitrary class) and if you do know what’s in the string, 
>>> why are you not creating the instance directly?
>>> 
>>> 
 On 14 Nov 2016, at 23:48, Rick Mann via swift-users 
  wrote:
 
 Thanks, David. That's interesting as a thought exercise, but doesn't 
 really get me away from having switch statements. I'll probably end up 
 just "slightly polluting" my classes by adding extension methods to create 
 the appropriate auxiliary classes. Sure wish Swift supported optional 
 methods without @objc (I guess it's not that big a deal to use @objc).
 
> On Nov 13, 2016, at 11:19 , David Sweeris  wrote:
> 
> 
>> On Nov 13, 2016, at 1:55 AM, Rick Mann  wrote:
>> 
>> 
>>> On Nov 12, 2016, at 22:47 , David Sweeris  wrote:
>>> 
>>> 
 On Nov 13, 2016, at 00:38, Rick Mann via swift-users 
  wrote:
 
 So, it seems there's still no way to do something like instantiate a 
 class given only its name (as a String)?
 
 In my situation, I have a number of subclasses (or protocol 
 implementations), which parallel some other class hierarchy. I need to 
 dynamically create one based on the name of another. I don't want the 
 latter classes to "know" anything about the former.
>>> 
>>> Not that I know of... If this is all your code, can you fake it by 
>>> switching over the type's name?
>> 
>> Yeah, it just happens in a few places, would be nice to write the code 
>> once and then just ensure classes exist. I know I could do it 
>> subclassing NSObject, but Swift really ought to have proper reflection.
> 
> Reflection is on the todo list (although I can’t recall if it’s in-scope 
> for Swift 4).
> 
> There’s also the possibility of putting the names of the classes you want 
> to instantiate into an enum. In fact, if all the classes in question have 
> a common superclass, you could this:
> class MyAwesomeSuperClass { required init() {} }
> class MyAwesomeSubClass : MyAwesomeSuperClass {}
> class Whatever : MyAwesomeSuperClass {}
> class Etc : Whatever {}
> enum ClassNames : String {
> //Unfortunately the value of each case has to be a literal, so
> //you can’t just say `case etc = "\(Etc.self)"`
> case myAwesomeSuperClass = "MyAwesomeSuperClass"
> case myAwesomeSubClass = "MyAwesomeSubClass"
> case whatever = "Whatever"
> case etc = "Etc"
> init(_ instance: MyAwesomeSuperClass) { self = ClassNames.init(rawValue: 
> "\(type(of: instance))")! }
> init(_ type: MyAwesomeSuperClass.Type) { self = ClassNames.init(rawValue: 
> "\(type)")! }
> var type: MyAwesomeSuperClass.Type {
> switch self {
> case .myAwesomeSuperClass:  return MyAwesomeSuperClass.self
> case .myAwesomeSubClass:return MyAwesomeSubClass.self
> case .whatever: return Whatever.self
> case .etc:  return Etc.self
> }
> }
> }
> var etc = Etc()
> var className = 

Re: [swift-users] Reflection in Swift 3?

[Jeremy Pereira via swift-users]

> On 15 Nov 2016, at 10:33, Rick Mann  wrote:
> 
> Well, that's not really any different than a switch statement, in that it has 
> to be maintained.

Yes, but I would argue that it is a good thing because you need to do some 
validation before you instantiate the class anyway.

Furthermore, it gives you more flexibility in terms of initialisation because 
the closure can invoke any initialiser regardless of parameters and can do 
other processing as well.

> 
>> On Nov 15, 2016, at 01:50 , Jeremy Pereira  
>> wrote:
>> 
>> Perhaps I’m missing something here, but why not use a map?
>> 
>>   let factoryMap = [ String : () -> SuperClassOrCommonProtocol ] = [ 
>> “MySubClass" : { return MySubClass() }, … ]
>> 
>>   …
>> 
>>   guard let factoryMethod = factoryMap[theClassName] else { /* error */ }
>>   return factoryMethod()
>> 
>> This is an approach I always ended up taking in Objective-C anyway, because, 
>> if you don’t know what’s in the string, you need to validate it (imagine if 
>> the user of your app finds out that they can cause you to instantiate any 
>> arbitrary class) and if you do know what’s in the string, why are you not 
>> creating the instance directly?
>> 
>> 
>>> On 14 Nov 2016, at 23:48, Rick Mann via swift-users  
>>> wrote:
>>> 
>>> Thanks, David. That's interesting as a thought exercise, but doesn't really 
>>> get me away from having switch statements. I'll probably end up just 
>>> "slightly polluting" my classes by adding extension methods to create the 
>>> appropriate auxiliary classes. Sure wish Swift supported optional methods 
>>> without @objc (I guess it's not that big a deal to use @objc).
>>> 
 On Nov 13, 2016, at 11:19 , David Sweeris  wrote:
 
 
> On Nov 13, 2016, at 1:55 AM, Rick Mann  wrote:
> 
> 
>> On Nov 12, 2016, at 22:47 , David Sweeris  wrote:
>> 
>> 
>>> On Nov 13, 2016, at 00:38, Rick Mann via swift-users 
>>>  wrote:
>>> 
>>> So, it seems there's still no way to do something like instantiate a 
>>> class given only its name (as a String)?
>>> 
>>> In my situation, I have a number of subclasses (or protocol 
>>> implementations), which parallel some other class hierarchy. I need to 
>>> dynamically create one based on the name of another. I don't want the 
>>> latter classes to "know" anything about the former.
>> 
>> Not that I know of... If this is all your code, can you fake it by 
>> switching over the type's name?
> 
> Yeah, it just happens in a few places, would be nice to write the code 
> once and then just ensure classes exist. I know I could do it subclassing 
> NSObject, but Swift really ought to have proper reflection.
 
 Reflection is on the todo list (although I can’t recall if it’s in-scope 
 for Swift 4).
 
 There’s also the possibility of putting the names of the classes you want 
 to instantiate into an enum. In fact, if all the classes in question have 
 a common superclass, you could this:
 class MyAwesomeSuperClass { required init() {} }
 class MyAwesomeSubClass : MyAwesomeSuperClass {}
 class Whatever : MyAwesomeSuperClass {}
 class Etc : Whatever {}
 enum ClassNames : String {
  //Unfortunately the value of each case has to be a literal, so
  //you can’t just say `case etc = "\(Etc.self)"`
  case myAwesomeSuperClass = "MyAwesomeSuperClass"
  case myAwesomeSubClass = "MyAwesomeSubClass"
  case whatever = "Whatever"
  case etc = "Etc"
  init(_ instance: MyAwesomeSuperClass) { self = ClassNames.init(rawValue: 
 "\(type(of: instance))")! }
  init(_ type: MyAwesomeSuperClass.Type) { self = ClassNames.init(rawValue: 
 "\(type)")! }
  var type: MyAwesomeSuperClass.Type {
  switch self {
  case .myAwesomeSuperClass:  return MyAwesomeSuperClass.self
  case .myAwesomeSubClass:return MyAwesomeSubClass.self
  case .whatever: return Whatever.self
  case .etc:  return Etc.self
  }
 }
 }
 var etc = Etc()
 var className = ClassNames(etc)
 var newEtc = className.type.init()
 
 The same trick works if all the types in question conform to the same 
 protocol, too:
 protocol MyAwesomeProtocol {
  init()
  func toIntMax() -> IntMax
 }
 extension Int : MyAwesomeProtocol {}
 struct Five : MyAwesomeProtocol { func toIntMax() -> IntMax { return 5 } }
 enum ProtocolNames : String {
  case five = "Five"
  case int = "Int"
  init(_ instance: MyAwesomeProtocol) { self = ProtocolNames.init(rawValue: 
 "\(type(of: instance))”)! }
  init(_ type: MyAwesomeProtocol.Type) { self = 
 ProtocolNames.init(rawValue: "\(type)")! }
  var type: 

Re: [swift-users] Overload Resolution of Binary Operators

[Toni Suter via swift-users]

@David
If you would split up the statement like this...

let x = 0 *** 4
let result = x +++ 0

... the compiler would report an ambiguity error, because both overloads of *** 
are valid and of equivalent priority.
You could do something like this though:

let x: Int = 0 *** 4// picks f2
let result = x +++ 0// picks f4

or this:

let x: String = 0 *** 4 // picks f1
let result = x +++ 0// picks f3

Now the compiler has enough type information to know which overload to pick.

@Mark
Ok, thanks. I reported a bug at https://bugs.swift.org/browse/SR-3209 
 and assigned it to you.

@Rien
Yes, it is even possible to use the operators as the example above shows, but 
it is requires a bit more explicit
type information so that the type checker knows which overload to pick.

Thanks and best regards,
Toni

> Am 15.11.2016 um 08:41 schrieb Rien :
> 
> I seem to remember that while it is possible to define, the compiler will 
> yield an error if you try to use the functions (“cannot resolve”).
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
>> On 14 Nov 2016, at 23:05, Toni Suter via swift-users  
>> wrote:
>> 
>> Hi,
>> 
>> I would have expected that the following code reports an error, because
>> of ambiguous function overloads:
>> 
>> infix operator ***: MultiplicationPrecedence
>> infix operator +++: AdditionPrecedence
>> 
>> func ***(x: Int, y: Int) -> String {
>>  print("f1")
>>  return ""
>> }
>> 
>> func ***(x: Int, y: Int) -> Int {
>>  print("f2")
>>  return 0
>> }
>> 
>> func +++(x: String, y: Int) -> Int {
>>  print("f3")
>>  return 0
>> }
>> 
>> func +++(x: Int, y: Int) -> Int {
>>  print("f4")
>>  return 0
>> }
>> 
>> let result = 0 *** 4 +++ 0   // prints f2 and f4
>> 
>> 
>> As far as I can tell, there are two possible overload resolutions: f1 + f3 
>> or f2 + f4.
>> I thought that these two solutions get an "equivalent score" and therefore 
>> there would
>> be a compile error. However, that's not the case. Instead, the type checker 
>> picks
>> f2 and f4.
>> 
>> So, I guess my question is, whether there is some rule, that prefers
>> operators, which have the same argument types and the same return type
>> or whether this is simply a bug.
>> 
>> Thanks and best regards,
>> Toni
>> ___
>> 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