-
Notifications
You must be signed in to change notification settings - Fork 71
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
Collision detection #412
Collision detection #412
Conversation
…l information until collision detection and handling is done
# Conflicts: # modules/codegen/src/smithy4s/codegen/Renderer.scala # modules/example/src/smithy4s/example/GetObjectInput.scala # modules/example/src/smithy4s/example/LowHigh.scala # modules/example/src/smithy4s/example/ObjectService.scala # modules/example/src/smithy4s/example/PutObjectInput.scala # modules/example/src/smithy4s/example/StreamedObjects.scala # modules/example/src/smithy4s/example/StructureWithRefinedTypes.scala # modules/example/src/smithy4s/example/import_test/OpOutput.scala
2. renames ADT for modeling the code and imports 3. renderGetMessage returns Line 4. regenerate examples
added predef and package object scala imports to collision detection added test case to handle Set,List,Option,Map
Ain't got time to review proper before next week, but, I think the most desirable solution would be to remove the underscore-logic altogether in favour of a local rename. Say you have the following in a smithy model
then you'll have
Doing this would be facilitated by the fact that we're retaining structural information for longer, meaning we can transform the |
@Baccata I'm not using underscore for collision renaming. |
this will fix #255 too |
Adds logic to protect against rendering types using (non-fqn) names that Scala devs are bound to use when using smithy4s. (stdlib, smithy.Timestamp, etc). For instance, when encountering `foo#List`, then a `_List` scala type gets created instead. If `List` is the name of an operation, then the method created is `list`, in an effort to minimise the impact on user experience.
Conflicts: modules/example/src/smithy4s/example/package.scala
Draft to address collisions with stdlib types and keywords
keyword protection is done with underscore as using backticks (which would be idiomatic scala) creates a new problem where we append to names "Gen" or "Op" etc.. a backtick must wrap the entire identifier
I found this to be sufficient reason to avoid switching to backticks as it would involve significant code shuffling .
This draft is to be reviewed for correctness . I will be making further commits to address code conciseness and quality