-
Notifications
You must be signed in to change notification settings - Fork 27
New Config: de-duplicate setters/getters properties #90
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
Comments
Good catch 😄 , this was intentional indeed because we wanted to have lightweight |
|
Both approaches are very reasonable but clash with the idea of us not wanting to expose an extra type for the mere purpose of code deduplication. Still thank you for the effort and for bringing this up! 😄 |
Could you advise what is the reason for avoiding extra type, please? Btw, other possibility which is not available until approx. September is to use new swift macros (since 5.9) |
Generally, there is nothing speaking against this extra type. However, it just clutters our public API and we can never remove the extra type as adopters will most likely use this extra type in their codebase. Ultimately it comes down to if you're happy to live with some duplication or if you want to add a new type to the public API that can never be removed. When implementing the configuration back then we decided to go with the former. Btw, initially, I also wanted to use protocol extension but then we decided against it (See this PR) And yes Swift Macros are great! However, we will probably want to support older Swift versions for still some time after September but for the future, the usage of Macros in our package is definitely worth investigating! |
As @felixschlegel wrote this was an intentional move to duplicate some code. Introducing a Reducing code duplication is not always the goal when designing public APIs, but rather having correct and evolvable types. In the end, we just agreed that we can live with the duplication and avoid unnecessary protocols. |
De-dup of the code is not the goal itself. I am more concerned about possible losing some code in one of places when change it or add some thresholds and checks.
https://github.com/swift-server/swift-kafka-gsoc/blob/main/Sources/SwiftKafka/Configuration/KafkaProducerConfiguration.swift#L134 Security is defined within one place. So, any changes will be reflected for both Consumer and Producer configs. |
@felixschlegel, @FranzBusch thank you for your answers! |
As I see, there are a lot of properties duplicated in Producer and Consumer configurations.
As example:
and
Probably, it make sense to put them into one place and de-dup this code or I miss something and that was made intentionally.
@felixschlegel could you suggest on that, please?
The text was updated successfully, but these errors were encountered: