Reactivecocoa: Como devemos lidar com os prefixos `rac_` no Swift 3?

Poderíamos eliminar os prefixos, pois os tipos tornam os nomes inequívocos - pelo menos na maioria dos casos. Ou podemos mantê-los. Estou em cima do muro.

Se os mantivermos, devemos usar rac_ aqui (incluindo o código de Rex) e encontrar um novo prefixo para ReactiveSwift.

Visto que eliminar o prefixo das ligações causaria conflitos de nomes com as propriedades armazenadas, uma alternativa para elas seria a introdução de um proxy que hospedasse todas elas.

por exemplo

view.bindables.text <~ property

// `view.bindables` is of type `Bindings<UIView>`, which conforms to `BindingsProtocol`
// that requires an associated type `Owner`.
//
// `view.bindables.text` is provided by the extension to `BindingsProtocol` for all
//`Owner` inherited from `UIView`.

(Ou apenas rac ? Mas tanto ReactiveSwift quanto ReactiveCocoa podem expor algum tipo de vinculação, suponho)

... Ou apenas nomeie como view.textProxy , view.reactiveText ou qualquer outra coisa, eh.

Edit: Eu montei um protótipo rápido (https://github.com/RACCommunity/Rex/pull/143).

Edição 2: Limpe um pouco a bagunça. : p

ReactiveCocoa 5+ não precisa ser compatível com Rex. RAC irá incluir Rex.

Claro, eu só quis dizer aquelas ligações trazidas por Rex. Desculpe se parece uma bagunça. 😸

outlets também seria um candidato.

"reativo" fica melhor com linguagem rápida. "rac_" e "rex_" são nomes muito ruins. Vou escolher "reativo", "ativo" ou "sinal" para que possamos ter view.reactiveText ou view.activeText ou view.signalText

Com o Swift e os módulos, não há mais o risco de colisões em tempo de execução e, portanto, não há necessidade de prefixos. Então, vamos largá-los! : D

É bom para os métodos. Mas ainda precisamos procurar uma abordagem para as propriedades, uma vez que as propriedades não podem ser sobrecarregadas. 😕

Construído sobre um proxy bindable por exemplo view.bindables.something , podemos introduzir atalhos como %view.something . 😕

Eu acho que é seguro tirar a conclusão de que não podemos evitar / desambiguar colisões em tempo de compilação de nenhuma forma, pelo menos no Swift 3.0. Sugestões como o uso de operadores ou propriedade mágica apenas limitam o potencial de colisão a uma entidade.

Eu arriscaria uma colisão com a operadora em troca de uma abreviatura mais agradável ...

Acho que estamos presos aos prefixos de propriedades por enquanto.

Uma das coisas que fizemos com o SnapKit foi criar uma estrutura que hospeda as extensões, as APIs RAC podem ser armazenadas como:

struct UIButtonRACDSL {
    var pressed: Signal<UIButton, NoError>
    init(button: UIButton) { }
}

extension UIButton {
    var rac: UIButtonRACDSL { return UIButtonRACDSL(button: self) }
}

A descida desta rota fornece alguma flexibilidade e reduz o escopo de colisão das extensões.

Sim, eu mencionei isso antes com uma versão baseada em protocolo. Ele substitui o sublinhado por um ponto e permite a introdução de uma abreviação de operador. IMO usando rac como o nome da propriedade seria adequado, pois não é uma abreviatura muito comum de qualquer maneira.

https://github.com/RACCommunity/Rex/pull/143

rac propriedade ficaria muito mais limpa ... MUUUITO !!! :olhos do coração:

Acho que devemos roubar a abordagem que o RxSwift adotou.

https://github.com/ReactiveX/RxSwift/blob/4952adb27c684b47792923b00015516849061eab/RxCocoa/Common/Reactive.swift
https://github.com/ReactiveX/RxSwift/blob/4952adb27c684b47792923b00015516849061eab/RxCocoa/iOS/UIControl%2BRx.swift

Eles adicionaram uma estrutura, Reactive que é genérica em relação ao tipo que desejam estender. Em seguida, eles adicionaram métodos em extensões restritas a Reactive . Evidentemente, eles modelaram isso após .lazy Swift.

Talvez não seja roubo.

https://github.com/RACCommunity/Rex/pull/143/commits/86f03c3b2d4759c87254a9ea3b28939f23f6be56
😜