Reactivecocoa: Bagaimana seharusnya kita menangani awalan `rac_` di Swift 3?

Dibuat pada 10 Jul 2016 · 15Komentar · Sumber: ReactiveCocoa/ReactiveCocoa

Pedoman Swift API menetapkan konvensi kasing unta yang lebih rendah.

Saat ini, kami memiliki dua pengecualian dalam basis kode Swift: NotificationCenter.rac_notifications(forName:object:) dan URLSession.rac_data(with:) . Selain itu, karena IIRC kita akan menggabungkan Rex sebagai bagian dari repo Cocoa Bindings di beberapa titik, bagaimana awalan rex_ ditangani harus dipertimbangkan juga.

Haruskah kita mengikuti, atau membiarkan mereka apa adanya?

Untuk dua ekstensi dalam repo ini, nama yang paling tidak kreatif mungkin adalah `makeProducer` .
Mulailah nama metode pabrik dengan "make", egxmakeIterator().
Sunting: Setelah berpikir dua kali, untuk produsen, mereka tidak memiliki efek samping yang diterapkan sampai mereka dimulai. Jadi nama yang tidak bermutasi yang menjelaskan apa yang akan diberikannya akan menjadi IMO yang sesuai, misalnya hanya `notifications(forName:object:)` .

Sumber

andersio

Komentar yang paling membantu

Salah satu hal yang telah kami lakukan dengan SnapKit adalah membuat struct yang menampung ekstensi, api RAC dapat disimpan seperti:

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

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

Menuruni rute ini memberikan beberapa fleksibilitas dan mengurangi cakupan tabrakan ekstensi.

robertjpayne pada 9 Agu 2016

👍5 ❤2

Semua 15 komentar

Kita bisa menghilangkan awalan karena tipenya membuat namanya tidak ambigu—setidaknya dalam banyak kasus. Atau kita bisa menyimpannya. Aku di pagar.

Jika kita menyimpannya, kita harus menggunakan rac_ sini (termasuk kode dari Rex) dan menemukan awalan baru untuk ReactiveSwift.

mdiep pada 11 Jul 2016

Karena menghapus awalan dari binding akan menyebabkan tabrakan nama dengan properti yang disimpan, alternatif untuk ini adalah memperkenalkan proxy yang menampung semuanya.

misalnya

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

(Atau hanya rac ? Tapi baik ReactiveSwift dan ReactiveCocoa dapat mengekspos beberapa jenis binding, saya berasumsi)

... Atau sebut saja view.textProxy , view.reactiveText atau apalah, eh.

Sunting: Saya telah mengumpulkan prototipe cepat (https://github.com/RACCommunity/Rex/pull/143).
Sunting 2: Bersihkan kekacauan sebentar. :P

andersio pada 11 Jul 2016

ReactiveCocoa 5+ tidak perlu kompatibel dengan Rex. RAC akan memasukkan Rex.

mdiep pada 11 Jul 2016

Tentu, maksud saya hanya ikatan yang dibawa oleh Rex. Maaf kalau bacaannya berantakan. 😸

andersio pada 11 Jul 2016

outlets akan menjadi pesaing juga.

andersio pada 12 Jul 2016

"reaktif" lebih cocok dengan bahasa Swift. "rac_" dan "rex_" adalah penamaan yang sangat buruk. Saya akan memilih "reaktif", "aktif" atau "sinyal" sehingga kita dapat memiliki view.reactiveText atau view.activeText atau view.signalText

bobgodwinx pada 15 Jul 2016

Dengan Swift dan modul, tidak ada lagi risiko tabrakan runtime, dan karenanya tidak perlu awalan. Jadi mari kita jatuhkan mereka! :D

NachoSoto pada 18 Jul 2016

👍2

Itu bagus untuk metodenya. Tetapi kita masih perlu mencari pendekatan untuk properti, karena properti tidak dapat di-overload. 😕

Dibangun di atas `bindable` proxy misalnya `view.bindables.something` , kami dapat memperkenalkan pintasan seperti `%view.something` . 😕

andersio pada 18 Jul 2016

Saya pikir aman untuk menarik kesimpulan bahwa kita tidak dapat menghindari/menyamarkan tabrakan waktu kompilasi dengan cara apa pun, setidaknya di Swift 3.0. Saran seperti menggunakan operator atau properti ajaib hanya membatasi potensi tabrakan ke satu entitas.

Saya akan mengambil risiko tabrakan operator dengan imbalan steno yang lebih bagus ...

andersio pada 25 Jul 2016

Saya pikir kita terjebak dengan awalan untuk properti untuk saat ini.

mdiep pada 26 Jul 2016

Salah satu hal yang telah kami lakukan dengan SnapKit adalah membuat struct yang menampung ekstensi, api RAC dapat disimpan seperti:

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

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

Menuruni rute ini memberikan beberapa fleksibilitas dan mengurangi cakupan tabrakan ekstensi.

robertjpayne pada 9 Agu 2016

👍5 ❤2

Ya, saya telah membahasnya sebelumnya dengan versi berbasis protokol. Ini menggantikan garis bawah dengan titik, dan memungkinkan pengenalan singkatan operator. IMO menggunakan rac sebagai nama properti akan baik-baik saja, karena ini bukan singkatan yang sangat umum.

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

andersio pada 9 Agu 2016

👍1

Properti rac akan terlihat jauh lebih bersih… SANGAT MUUUCH!!! :hati_mata:

iby pada 14 Agu 2016

Saya pikir kita harus mencuri pendekatan yang telah diambil RxSwift.

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

Mereka menambahkan struct, Reactive yang generik di atas jenis yang ingin mereka perluas. Mereka kemudian menambahkan metode pada ekstensi terbatas ke Reactive . Jelas mereka membuat model ini setelah Swift .lazy .

mdiep pada 19 Sep 2016

👍1

Mungkin bukan mencuri.

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

andersio pada 19 Sep 2016

😄1

Apakah halaman ini membantu?

0 / 5 - 0 peringkat