Decide on File naming for RxCocoaExt(s) and RxSwiftExt(s)

[freak4pc]

Description

This ticket continues discussion on one of the point form #127.

Would appreciate some opinions on what you guys would consider proper naming for files.

In an optimal world we could keep the same naming across RxSwift and RxCocoa components.

e.g.

• RxSwift
  • distinct.swift
• RxCocoa
  • distinct.swift

But swiftc won't compile two filenames of the same name, even if they don't contain any definition conflicts.

Right now the naming seems to follow

• RxSwift
  • distinct.swift
• RxCocoa
  • distinct+RxCocoa.swift

Does anyone have any nicer ideas of how to name these files ?
Thoughts I sort of have ATM:

• distinctSwift.swift, distinctCocoa.swift might be a bit meh?
• having a single distinct.swift file in a Common folder (same level as RxSwift and RxCocoa) for every filename that has extensions that are relevant for both. But actually this won't work since there won't be a good way to subspecies these... (maybe build flags)

This is a bit of a tricky subject so would appreciate any help.

Anyways, For tests It would just be the same with Tests.swift appended to the end of whatever filename, to keep things consistent.

Also for naming in general, seems there was an agreement for:

• Class Case for classes (including XCTestCase subclasses)
• camelCase for operators

Thanks for any assistance in naming :)

[fpillet]

IMHO, the distinct+RxCocoa.swift form is the tried and true way of naming category files in Obj-C and has worked well for years. We should use it wherever the file name overlaps an existing one from the Swift folder (considered the baseline for file names).

Regarding tests, the Tests.swift extension look good to me as well.

Casing rules are 👍

[freak4pc]

Thanks for taking the time to comment @fpillet :)

the distinct+RxCocoa.swift form is the tried and true way of naming category files in Obj-C

In general I agree. The problem is we aren't naming the RxSwift counterparts as distinct+RxSwift - meaning RxSwift is "main" and RxCocoa is secondary in some sort? Not sure if that's a problem but wanted to bring it out there.

[fpillet]

This is actually my idea. You can't have RxCocoa without RxSwift anyway, so it doesn't make real sense (other than purely aesthetic) to force naming distinct+RxSwift.swift.

Another idea I have, since RxCocoa is all about UI, would be to name distinct+UI.swift. What do you think?

[freak4pc]

Actually that's a fair point about RxSwift being the "base".

I think since distinct isn't applied specifically to UI components, but just to these RxCocoa additions, we can keep the current +RxCocoa.swift naming. Sounds good?

[fpillet]

Sure, sounds good!

[mosamer]

@freak4pc Sorry for late reply, but I think it is possible to have same file names on RxSwiftExt/RxCocoaExt (which is optimal IMO) once they are separated into two projects (as per the existing plan). swift error is happening when the 2 files belong to the same target. Here is a link to a sample workspace I believe we should finally look similar to.

[freak4pc]

Thanks @mosamer !
As we discussed privately that's an interesting point but we actually just discussed different Podspecs or Subsepcs. Neither necessarily mean we need separate projects.

Besides solving the "duplicate filenames" thing I'm worried this will just add more overhead to maintain several Xcodeprojs. What do you guys think? @fpillet

Also not sure, we might actually be forced to do this to let Carthage users granularly install RxSwiftExt or RxCocoaExt separately (is this really a worth cause here? I think @bobgodwinx understands Carthage better than the rest of us so would love your opinion!)

[bobgodwinx]

Happy holidays to you all. @freak4pc I think there is no need to have duplicate files or filename. For any operator that is used in both projects I would prefer going for a shared structure. For example distinct can go into the shared directory if it is used by both, while every other file should be strictly project related and should stay in project specific directory. So we could have a structure

• Current Workspace Directory
  1. RxSwiftExt.xcworkspace
  2. RxSwiftExt.xcodeproj
  3. RxCocoaExt.xcodeproj
  4. RxSwiftExt.podspec
  5. RxCocoaExt.podspec
  6. RxSwiftExt - Directory
  7. RxCocoaExt - Directory
  8. Shared - Directory
  9. RxSwiftExtTests - Directory
  10. RxCocoaExtTests -Directory

This is just an example of how it could be structured. Although Carthage will clone the entire repository but it will make builds with specific files related to each project. So someone can opt to use RxSwiftExt without RxCocoaExt or the other way round.

• Draw backs

1. The first problem I foresee here is that here is that when a shared operator is broken because of one project update then other is also broken.
2. Updates are almost coupled. Because when you create a tag for a new podspecs related to one project then Carthage will always see it as a new version for both even though there are no changes in the other.

[freak4pc]

@bobgodwinx We can't go with that approach since that would force you to install RxSwiftExt and RxCocoaExt together, without any granularity. We want separate file for the separate projects

[fpillet]

Also, it's better to keep file names distinct to shield against debugging issues with similar file names in the same framework. May confuse poor LLDB

[bobgodwinx]

@fpillet @freak4pc this structure is actually allowing you to install RxSwiftExt or RxCocaExt I will make an example on different Repo to show how it looks.

[freak4pc]

Sure, let me see what you're thinking of :) thanks @bobgodwinx