Open freak4pc opened 6 years ago
Separating the Operators
from Common
might not work for all cases. Some operators also have a static variant (like the and
and cascade
operators which provide both static and instance methods).
If we were to move each to separate folders, I'm not sure it would help making a mental image of the various functionalities exposed by RxSwiftExt.
It seems difficult to design a one-size-fits-all rule for this. There are other examples in the framework where naming is odd, like materialize+Elements.swift
which was named like this to avoid conflicts with same file name in RxSwift, while providing another operator (errors()
) which is not advertised by the actual file name. Also, flatMapSync
and filterMap
encompass several types of their own, which is another friction point (since they are public).
My take on this would be to:
RxSwiftExt
and RxCocoaExt
materialized+elements.swift
which could be split in
materialize+elements.swift
materiazlize+errors.swift
ObservableType+Weak.swift
which has several issues of its own:
subscribe
methods (I would prefer names that don't overlap those in RxSwift)@fpillet Good thoughts, thanks :)
My thought of separating was mainly in favor of RxCocoaExt - where operators and UI-related additions are entirely different and I feel like those shouldn't live in a single folder
For RxSwift I sort of agree most things could live in a single folder - Even though, extensions that have static methods are still operators; in RxSwift there isn't really much of a non-operator concept, so this is more related to RxCocoa as said earlier.
I'm not sure if we need a different file for each of these materialize operators... I think that could get a bit hairy, even though they are different operators so that should actually be fine. Does it mean the RxCocoa variants (if would exist) would be called materialize+elements+RxCocoa.swift
? A bit of a mouthful.
ObservableType+Weak is its own issue to take care of, I agree :) Still need to think about it, but for now it can live inside the RxSwift folder as usual.
So I think the folder structure I currently have in mind is
RxCocoa
I don't think the "Ext" on each folder is needed as the project itself is already RxSwiftExt, and the folders just indicate what each folder "Extends".
RxSwift follows an even more convoluted folder structure but I don't think that's at all required for the purposes of this repo: https://github.com/ReactiveX/RxSwift/tree/master/RxCocoa
Then why not:
This was we can put stuff like ControlEvents in Common
and platform-specific ones in their respective folders.
That's cool actually! The only problem with this is that components that have platform agnostic controls such as
typealias OSControl = UIButton
vs typealias OSControl = NSButton
variation would have to be split out in the two folders and I'm not entirely sure that's possible
Or those would be in "Common" ? Because that would mean we have Operators and Multi-platform UI living in a single folder, which beats the reasoning of trying to separate logically (unless you have UIKit
, AppKit
,Common
and Operators
or Core
)
Description
This ticket continues discussion on one of the point form #127.
Would appreciate some opinions on what you guys would consider optimal Folder Structure and file-naming for RxSwift and RxCocoa related additions, at your spare time :)
Copying from the "Big issue":
Any opinions would be welcomed so I can move forward on this change :)
Thanks Shai