Open N129BZ opened 3 years ago
Can't say that I fully understand the value of doing such renaming in this particular case (especially given that the main benefit hinted seems to be easiness of refactoring in future, while, by definition, should not happen with generated code) — but, as they say, when in Rome, do as the Romans do.
@N129BZ, do you have any suggestions how shall we name such parameters?
The formal convention in GO is to use a single letter or as few as possible, so it could be s for stream, p for parent, r for root, etc.
Just wanted to comment that this is relevant for other languages too. I'm experimenting with a Common LISP language implementation, and the object system there also uses named parameters for self.
Their conventions are different, so this isn't necessarily relevant to this issue, but I'm curious on the steps this issue takes to get resolved.
object is a common name there, or a name specific to the class, e.g. kaitai-struct for a kaitai-struct object (the type name would have to be different).
Edited to add: it doesn't have to be different, but it's probably less confusing. Again, Go may have different standards and styles.
So maybe ks for the object name and kaitai-struct for the name of the base class.
See: https://github.com/golang/go/wiki/CodeReviewComments#receiver-names
"Don't use generic names such as "me", "this" or "self", identifiers typical of object-oriented languages that gives the method a special meaning. In Go, the receiver of a method is just another parameter and therefore, should be named accordingly. "
See also: https://blog.heroku.com/neither-self-nor-this-receivers-in-go