IMO the best arguments for using methods have nothing to do with language semantics, but are just grug-brained "this makes my life easier" stuff. Methods are great because they work unreasonably well with autocomplete, they're very easy to find in API docs, and they let you write easily readable call chains without a 10 nested levels of parentheses that need to be read inside-out. Plus, as the article says - it's sometimes nice to have another code organization tool at your disposal.
Good blog post, good balance. One thing to add is that in systems programming, very often the struct is not arbitrarily defined by the programmer - it may be defined by the hardware or another system entirely. So the Data, including its bit-by-bit layout, is primal. It kind of makes sense to have procedures to operate on it, rather than methods.
Why should the first argument be so special? And how do you decide which struct should get method if you have a function that operates on two different types?
IMO the best arguments for using methods have nothing to do with language semantics, but are just grug-brained "this makes my life easier" stuff. Methods are great because they work unreasonably well with autocomplete, they're very easy to find in API docs, and they let you write easily readable call chains without a 10 nested levels of parentheses that need to be read inside-out. Plus, as the article says - it's sometimes nice to have another code organization tool at your disposal.
Good blog post, good balance. One thing to add is that in systems programming, very often the struct is not arbitrarily defined by the programmer - it may be defined by the hardware or another system entirely. So the Data, including its bit-by-bit layout, is primal. It kind of makes sense to have procedures to operate on it, rather than methods.
Not a fan of methods.
Why should the first argument be so special? And how do you decide which struct should get method if you have a function that operates on two different types?