Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Splitting of Filters+Strings #63

Merged
merged 10 commits into from
Aug 23, 2017
Merged

Splitting of Filters+Strings #63

merged 10 commits into from
Aug 23, 2017

Conversation

Antondomashnev
Copy link
Contributor

This resolves the #58, naming selection was pretty difficult, but so far it looks ok to me. @AliSoftware @djbe if you have better names - I'd be happy to change it 😄

///
/// - Parameter string: The string to titleCase
/// - Returns: The string with its first character uppercased, and the rest of the string unchanged.
private static func titlecase(_ string: String) -> String {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename this to upperFirstLetter, titlecase is the old name for this filter/function.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why that titlecase name came back up here, did you copy/paste the code from before the last commits which changed that name when you started working on that split? Or did we miss something when doing our latest merges and let that slip?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AliSoftware when I cloned the repo today the initial state was 49af697

Copy link
Contributor Author

@Antondomashnev Antondomashnev Aug 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AliSoftware I think you messed up something as we're still using titlecase 😄
But we maybe can remove it and use only upperFirstLetter as @djbe commented.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In c4686c3 it's removed, but I had to create a function upperFirstLetter that doesn't throw and takes String parameter to be able to use in:

let comps = string.components(separatedBy: "_")
unprefixed = comps.map { upperFirstLetter($0) }.joined(separator: "")

/// - string: the value to be processed
/// - stripLeading: if false, will preserve leading underscores
/// - Returns: the camel case string
static func snakeToCamelCase(_ string: String, stripLeading: Bool) throws -> String {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be moved to private, except that swiftIdentifier depends on it.

Should we have a clearer separation between the Stencil filter functions (that accept and return Any), and the actual filter methods (that accept and return String + typed arguments)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, maybe internal real functions should be separate to functions having a Filter signature and being used in registerFilter… but then where should we put that static func snakeToCamelCase method?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the:

Should we have a clearer separation between the Stencil filter functions (that accept and return Any), and the actual filter methods (that accept and return String + typed arguments)?

I wanna ask if it makes sense for you to validate input not for string, but for string convertable. That would actually be a benefit for Sourcery and simplify the template writing 😄

Copy link
Member

@djbe djbe Aug 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Antondomashnev so this then?

guard let value = value as? CustomStringConvertible else {...}
let string = value.description

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like a good idea to me, we don't care what the data is as long as we can safely convert it to a string.

Copy link
Contributor Author

@Antondomashnev Antondomashnev Aug 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@djbe exactly.
Cool, I guess it worth another PR, as to not mess up things 😄

@djbe
Copy link
Member

djbe commented Aug 20, 2017

While we're at it, maybe check on codebeat if there are other changes we might want to apply:
https://codebeat.co/projects/github-com-swiftgen-stencilswiftkit-master/report_classes/swift-Filters-Strings
Note that some issues are already resolved by this PR (see the codebeat CI step).

@@ -385,7 +387,9 @@
2E92B989035E25169DF9300616F23AAB /* Environment.swift */,
0C6D246B203676EC17FA9473D97CB418 /* Filters.swift */,
02B0A9A1128124B1A17D5AB1E23A0A45 /* Filters+Numbers.swift */,
47DB41142F62E8B5174F3DF281DCD5E3 /* Filters+Strings.swift */,
6D1EF02F1F49EC7C00EA91EF /* Filters+Strings+Lettercase.swift */,
6D1EF02B1F49E85D00EA91EF /* Filters+Strings+Mutations.swift */,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those short UUIDs intrigue me… is this a new thing in Xcode 9, shorter UUIDs for file references in Xcodeprojs? 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It happens when you add the files manually to the pods project. When you run pod install you get the longer UUIDs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @djbe didn't know it. @AliSoftware I used Xcode 8.x but added the, manually.

import Stencil

extension Filters {
enum Strings {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmmh. There's no particular reason why the enum would be declared in +Boolean and extension be used in the other files… But is it worth having a Filters+Strings.swift which would only declare an empty enum Strings{} just so all Filters+Strings+Whatever.swift subsequent file are consistent and all use extension Filters.Strings?

Copy link
Contributor Author

@Antondomashnev Antondomashnev Aug 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea, I think it may be clearer for developer, that there is a "base" file.

/// - string: the value to be processed
/// - stripLeading: if false, will preserve leading underscores
/// - Returns: the camel case string
static func snakeToCamelCase(_ string: String, stripLeading: Bool) throws -> String {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, maybe internal real functions should be separate to functions having a Filter signature and being used in registerFilter… but then where should we put that static func snakeToCamelCase method?

///
/// - Parameter string: The string to titleCase
/// - Returns: The string with its first character uppercased, and the rest of the string unchanged.
private static func titlecase(_ string: String) -> String {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why that titlecase name came back up here, did you copy/paste the code from before the last commits which changed that name when you started working on that split? Or did we miss something when doing our latest merges and let that slip?

@AliSoftware
Copy link
Contributor

@Antondomashnev you might want to (1) rebase your branch on top of master now that we recently released SwiftGenKit 2.1.0 (as of minutes ago), and also double and triple-check that what you did cut&paste in separate files didn't get changed by recent commits, making you miss those changes (see the titlecase case) and risking introducing regressions.

Otherwise I'm ok with the names (or rather I can't think of anything better at the moment :-p), thanks for the PR :)

@djbe
Copy link
Member

djbe commented Aug 20, 2017

I think the code is based on almost the most recent code. titlecase was an old internal method from before the filter got renamed. I think it got missed during the rename and addition of new filters.

@Antondomashnev
Copy link
Contributor Author

@AliSoftware @djbe the build is failing because the file Filters+Strings has not been compiled yet, when the Filters+Strings+... are compiling. I've worked around it with build and test from Xcode, but haven't found solution yet for SPM. If you have an idea that would be helpful.

The simplest way to fix it would be to keep the decalaration of enum Strings as it was in Filters+Strings+Boolean but I do like much more the separate file with declaration.

@AliSoftware
Copy link
Contributor

AliSoftware commented Aug 21, 2017

I'm not sure I understand how, in the case where the enum is in Filters+Strings it might not be compiled before, but when it's in Filters+Strings+Boolean it's guaranteed to be compiled before Filters+Strings+Lettercase for example?

@djbe
Copy link
Member

djbe commented Aug 21, 2017

@Antondomashnev Is it because you added the files to the pods project manually? Order really shouldn't matter. Try running bundle exec pod install.

@Antondomashnev
Copy link
Contributor Author

@AliSoftware I don't understand as well.

But as I wrote in the comment above:

The order of compile sources must be like that, so Filters+Strings.swift is compiled first 😄

@Antondomashnev
Copy link
Contributor Author

Antondomashnev commented Aug 21, 2017

@djbe tried it, didn't help. Also tried to remove references for these files, add them again and bundle exec pod install, still no luck.

                31BF3597506A8E41463703B4BA2D71C0 /* Filters+Strings+Boolean.swift in Sources */ = {isa = PBXBuildFile; fileRef = 4A3294DE3EE416417CD5A353929BF3A3 /* Filters+Strings+Boolean.swift */; };
		3378EE87DA9FB9454669D5D5191B4E98 /* StencilSwiftKit-umbrella.h in Headers */ = {isa = PBXBuildFile; fileRef = 4DD3B54D1D2C564D5BA9E996D9CD9883 /* StencilSwiftKit-umbrella.h */; settings = {ATTRIBUTES = (Public, ); }; };
		3CFC4A8C135BD9D5BB28AFB16945E761 /* Parameters.swift in Sources */ = {isa = PBXBuildFile; fileRef = 8454F301FD8C9C5EB0330C86D7159347 /* Parameters.swift */; };
		4049984A2C747903582DA0EEDBC1C5DD /* StencilSwiftKit-dummy.m in Sources */ = {isa = PBXBuildFile; fileRef = 81075406C503A904C5D107F68764358A /* StencilSwiftKit-dummy.m */; };
		42E2D5056604852C8C89AE1FCD112B0A /* FilterTag.swift in Sources */ = {isa = PBXBuildFile; fileRef = 3D9976A9FB02F6316003996E10007AEE /* FilterTag.swift */; };
		45C9D21646ED334EA4C9B1DBC549D57E /* Filters+Numbers.swift in Sources */ = {isa = PBXBuildFile; fileRef = 9227E56C42EDA867A814F83D87325E4C /* Filters+Numbers.swift */; };
		486756099E4375C92AEEDD9DBC50C6A6 /* StencilSwiftTemplate.swift in Sources */ = {isa = PBXBuildFile; fileRef = 40BFBD138B4E950E8D24A35620CE4CCC /* StencilSwiftTemplate.swift */; };
		5245ABB6A66FF1DEC56583EF468DD7AA /* PathKit-umbrella.h in Headers */ = {isa = PBXBuildFile; fileRef = C62389B5756FDBA46714335EE5B2079D /* PathKit-umbrella.h */; settings = {ATTRIBUTES = (Public, ); }; };
		539BA0FADD1A22A8319F23AC2757AB0A /* SetNode.swift in Sources */ = {isa = PBXBuildFile; fileRef = ADE4751F2E4F5541BF77BAB13BE069CF /* SetNode.swift */; };
		5D5EC19E156C47504B777C0EA9DD7337 /* NowTag.swift in Sources */ = {isa = PBXBuildFile; fileRef = 0D3CBAF672FD3CA25D7EE1A8E93A6F07 /* NowTag.swift */; };
		5DEF23C8870F6D838AF561730C58977B /* Lexer.swift in Sources */ = {isa = PBXBuildFile; fileRef = 31A007C042C580A003C9B6DB5AD1B534 /* Lexer.swift */; };
		6272EE69D3F5DE1DF030E2B979A19909 /* PathKit.swift in Sources */ = {isa = PBXBuildFile; fileRef = 5B85A6D36EC20031BC5814F8D8D514E8 /* PathKit.swift */; };
		640F760024085F7314950766AD350F39 /* Filters.swift in Sources */ = {isa = PBXBuildFile; fileRef = 2C00655023ABE55F6948E0BFBEB532BC /* Filters.swift */; };
		6B27B2AFB03689DC6884F270293F7C4C /* Filters+Strings.swift in Sources */ = {isa = PBXBuildFile; fileRef = 4ACD468B2E8B13C3250DB2C01EE06C5D /* Filters+Strings.swift */; };

@djbe you can see that Filters+Strings+Boolean.swift is before Filters+Strings.swift, and it's because it seems to be sorted by UUID at least it looks like.

@Antondomashnev
Copy link
Contributor Author

@djbe @AliSoftware order definitely doesn't matter, but SPM still fails 😄

@AliSoftware
Copy link
Contributor

Does SPM uses -WMO? Or if not any way to enable it? I wonder if that would make a difference, forcing to compile it as a whole…

@Antondomashnev
Copy link
Contributor Author

Antondomashnev commented Aug 21, 2017

@AliSoftware do you mean whole module optimisation?

@AliSoftware
Copy link
Contributor

Yup

@Antondomashnev
Copy link
Contributor Author

@AliSoftware seems it does use it in release build and swift build -c release also doesn't work:

Also the Swift Package Manager compiles with whole-module optimizations in release builds.

@Antondomashnev
Copy link
Contributor Author

Yeah, I've made it working. So it seems for the SPM the file names are still matter and I think it's somehow sorted so the Filters+Strings.swift goes after Filter+Strings+....swift.
I've renamed Filters+Strings.swift to Filters+Strings+Base.swift so if we sort it alphabetically which is a guess from my side it becomes the first through all of extensions.

@AliSoftware
Copy link
Contributor

Ok, that's cool… but it's still worth a JIRA in bugs.swift.org to me though, as I think that shouldn't be the case 😉

@Antondomashnev
Copy link
Contributor Author

@AliSoftware very valid point, create one. Btw I still can not merge the PRs, maybe master is protected with some rules.

@AliSoftware
Copy link
Contributor

Yup, only the CoreTeam have right to merge into master 😉

@AliSoftware AliSoftware merged commit b6841ce into master Aug 23, 2017
@AliSoftware AliSoftware deleted the reduce_strings_filters branch August 23, 2017 07:41
@AliSoftware AliSoftware mentioned this pull request Mar 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants