Come notato da @Kirsteins, Swift ora rileva i simboli in conflitto tra Swift e Obj-C e simboli rapidi che causerebbero il dolore Obj-C. In aggiunta alla risposta data, si può evitare questo, in generale, specificando un'etichetta necessaria per i tipi supplementari, cambiando così la firma di chiamata:
import Foundation
extension NSObject {
func foo(d:Double, i:Int) { println("\(d), \(i)") }
func foo(withInt d:Int, i:Int) { println("\(d), \(i)") }
}
let no = NSObject()
no.foo(withInt:1, i: 2)
di là di questo, però, e per rispondere alla tua domanda immediata, si sta cercando per applicare gli idiomi Obj-C a Swift. Che cosa si vuole veramente, è o implementare didSet
(più probabile), o, eventualmente, set
:
class WhatIDidLastSummer {
var vacation:Bool = false {
didSet {
// do something
}
}
var staycation:Bool {
get { return true }
set {
// do something
}
}
}
fonte
2015-02-20 00:13:28
Questo sembra implicare che l'overloading dei metodi non è possibile in classi come UIViewControllers o, in effetti, qualsiasi classe che sottoclasse qualsiasi classe dell'obiettivo-c. È corretto? –
Sembra che la soluzione alternativa sia dichiarare privati. In questo modo il compilatore non tenterà di convertirli in ObjC, quindi non ci sarà un conflitto. – kwerle
@kwerle Soluzione eccezionale. Non ci avevo pensato prima. – Kirsteins