A new CodeGenerator.createFile method with more flexibility #1041
Conversation
There was a problem hiding this comment.
Overall this looks good, but I would refrain from introducing a new FileType enum, this is helpful but will make the 2 createNewFile() apis inconsistent in terms of the way they handle file types. If necessary we can introduce FileType later in a uniformed way for all APIs, for now just checking the extension name should help, unless we have a use case for example, generating .java files into resource directory?
|
@neetopia Having to pass in an extension as a mechanism to choose a directory doesn't make sense in the cases where there is no file extension. In addition, if the fileType was changed to In addition the translation between the extension and destination directory isn't obvious |
|
I am not completely against the idea of That being said, even if we want to use |
|
@neetopia I've made the changes we discussed on slack |
| * Used to determine where files should be stored when being | ||
| * created through the [CodeGenerator]. | ||
| */ | ||
| enum class FileType { |
There was a problem hiding this comment.
This FileType should be unnecessary then? I see that you do have usages in your code relying on this enum, but since we do not have any APIs exposing this enum, maybe we can put it in our implementations, if this enum helps with your implementation.
There was a problem hiding this comment.
Yeah, got rid of it
|
@neetopia Tests are passing |
|
you can run |
|
@neetopia The lint issue is resolved |
|
Merged, thanks for your PR! |
* Support creating files with a more flexible API * Change associate api to use extension (cherry picked from commit 1b5864d)
Problem:
The current API assumes classes are being created by enforcing package name and extension arguments. Many use cases for creating files include creating resources. This requires passing in a dummy "package name" and an empty extension in many cases. The processing of the package name argument assumes that dots should be replaced with slashes to represent separate directories. This prevents the creation of directories with dots in their name.
Solution:
This PR maintains the previous behavior with the existing API and introduces a new method to allow users more flexibility in the path being created. Suggestions welcome