Adding a param to customize the access modifier (supersedes #81)

[AliSoftware]

Closes #81

This is a follow-up of #81 which seemed to be a little bit abandoned by @txaiwieser

I used a little different take (just using --param public, as there's no practical use to make the constants something other than public or internal — generating private or file private constants would be useless) hence the separate PR.

• CHANGELOG
• Add tests which change that parameter when generating the output, to ensure it's taken into account on every declarations that matters

[djbe]

Just nitpicking:
Is public clear enough as a parameter? Can it cause conflicts at some future point?

[AliSoftware]

Good point, what about --param publicAccess?

[djbe]

Yeah, sounds good.

[AliSoftware]

Once #85 and #87 are merged we'll have to be careful to add the {{accessModifier}} to the lines changed in #85/#87 into this PR, so that the getter for imageName/colorName are affected by the internal/public param too

[djbe]

Unrelated to this PR (but noticed it while reviewing):

We still generate all the variations for swift 2, even though we don't compile these afterwards. Is it worth it keeping those around, and still generating them? They're marked as deprecated in the documentation.

templates/Tests/TemplatesTests/ColorsTests.swift

Line 35 in f17dc0a

test(template: "swift2",

It might be worth it, for unsupported swift versions, to not generate the variations and only have the default output.

[AliSoftware]

Tbh in even wonder if it's worth keeping Swift 2 templates at all…

[djbe]

Note: although it's not necessary to mark these as internal per se, I think it's good to actually do it, as it clearly communicates this to the user/developer.

[AliSoftware]

Yeah that's why I took that approach instead of the one in #81 where it was either public when on… and empty string when off.
I prefer the current approach both for balance in the template (as including the space in one case and nothing in the other and not having the space when using {{accessModifier}}func feels strange) and because making internal explicit feels more… well… explicit 😄

[djbe]

LGTM 👍

[djbe]

Up to Xcode 8, you can use swift 2.3.

I don't think anyone still uses it, and if they still do, they really should migrate. And if they really want, they can always use a custom template based on the current ones. But I vote remove them 👍 (separate PR though)

[AliSoftware]

Yeah that was my thought too. They can always use the templates as custom templates after making a copy of ours from the commit before we remove them 😜
Will likely remove in next version or during the big merge 😉