astefanutti edited a comment on pull request #2443: URL: https://github.com/apache/camel-k/pull/2443#issuecomment-870283574
> Thanks for the references. > > > More concretely, it is not possible to define a method outside the struct's package, so in the specific conditions.go example, it would not be possible to define methods for Deployment. > > Yes, sorry for not having made it clearer. This is what I meant. I think it's OK not to put those structs and methods together in the same files, we can keep those logics in `conditions.go`. My question is whether we should make them a method or function in `conditions.go`. I think I understood you. My point was that for Deployment, and the `getDeploymentCondition`, it would not be possible to declare it as a method in `conditions.go`, as `conditions.go` is not in the same package as the Deployment struct. > I personally like method because it makes it clear where the logic should belong. But the OO-neutral grammars of Go makes me confused on seeing which one is really benefitial. Not only this one but also there are many places where functions can be changed to methods in camel-k codebase. At the same time, though, I'm not sure if blindly converting fuctions to methods is a good thing. That's why I wanted to hear other's thoughts. Actually, in case of `conditions.go`, I'd tend to favor functions for that exact reason. The logic belongs to the Integration controller package, and are made private to enforce it. Setting conditions on Integration is the responsibility of the Integration controller, and should not be called outside of it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
