You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2021/08/02 17:00:08 UTC

[GitHub] [camel-k] astefanutti edited a comment on pull request #2443: chore: Polish Integration ready condition reconciliation

astefanutti edited a comment on pull request #2443:
URL: https://github.com/apache/camel-k/pull/2443#issuecomment-869481397


   > It's not a change request but a question for discussion: what are our general rules/guidelines of using functions vs methods in golang? Most of the functions defined in `conditions.go` seem to belong to `Integration` or `Deployment` to me, so as an OO lover I'd tend to go for methods over functions. But I see it's just a matter of taste in golang whether we put an arg to the beginning or in the middle of other args.
   
   That's a good question. Whether Golang is an Object-Oriented language depends on the definition of Object-Oriented language :) I don't think Golang advertises as an Object-Oriented language per se, even if some concepts are borrowed applicable, see https://golang.org/doc/faq#Is_Go_an_object-oriented_language. You can find a thorough analysis at https://spf13.com/post/is-go-object-oriented/, which concludes by _Welcome to the new ‘object’-less OO programming model_ 😃.
   
   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`.
   
   
   


-- 
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-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org