Reactivecocoa: Что делать с префиксами rac_ в Swift 3?

Мы могли бы отказаться от префиксов, поскольку типы делают имена однозначными - по крайней мере, в большинстве случаев. Или мы могли бы оставить их себе. Я на заборе.

Если мы их сохраним, мы должны использовать здесь rac_ (включая код от Rex) и найти новый префикс для ReactiveSwift.

Поскольку удаление префикса привязок вызовет конфликты имен с сохраненными свойствами, альтернативой для них будет введение прокси, на котором размещены все из них.

например

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`.

(Или просто rac ? Но я полагаю, что и ReactiveSwift, и ReactiveCocoa могут предоставлять какие-то привязки)

... Или просто назовите это view.textProxy , view.reactiveText или как угодно, а.

Изменить: я собрал быстрый прототип (https://github.com/RACCommunity/Rex/pull/143).

Изменить 2: немного очистить беспорядок. :п

ReactiveCocoa 5+ не обязательно должен быть совместим с Rex. RAC поглотит Рекса.

Конечно, я имел в виду те привязки, которые принес Рекс. Извините, если это похоже на беспорядок. 😸

outlets тоже будет претендентом.

"реактивный" лучше подходит для быстрого языка. «rac_» и «rex_» - очень плохие наименования. Я выберу «реактивный», «активный» или «сигнал», чтобы мы могли иметь view.reactiveText, view.activeText или view.signalText.

Благодаря Swift и модулям больше нет риска конфликтов во время выполнения и, следовательно, нет необходимости в префиксах. Так что давай просто бросим их! : D

Для методов это нормально. Но нам все равно нужно искать подход к свойствам, поскольку свойства не могут быть перегружены. 😕

Созданный на основе прокси bindable например view.bindables.something , мы можем ввести такие ярлыки, как %view.something . 😕

Я думаю, что можно с уверенностью сделать вывод, что мы не можем избежать / устранить неоднозначность коллизий во время компиляции каким-либо образом, по крайней мере, в Swift 3.0. Такие предложения, как использование операторов или магических свойств, просто ограничивают возможность столкновения одним объектом.

Я бы рискнул столкнуться с оператором в обмен на более красивую стенографию ...

Я думаю, что мы пока застряли с префиксами для свойств.

Одна из вещей, которые мы сделали с SnapKit, - это создание структуры, в которой размещаются расширения, API RAC может храниться следующим образом:

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

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

Переход по этому маршруту обеспечивает некоторую гибкость и уменьшает область конфликтов расширений.

Да, я уже упоминал об этом раньше с версией на основе протокола. Он заменяет подчеркивание точкой и позволяет использовать сокращение оператора. ИМО, используя rac качестве имени свойства, было бы хорошо, так как в любом случае это не очень распространенное сокращение.

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

rac свойство выглядело бы намного чище ... ТАК ОЧЕНЬ !!! : heart_eyes:

Я думаю, мы должны украсть подход, который использует RxSwift.

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

Они добавили структуру Reactive которая является универсальной по типу, который они хотят расширить. Затем они добавили методы для ограниченных расширений в Reactive . Очевидно, они смоделировали это по образцу .lazy Свифта.

Возможно, это не воровство.

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