3 ms·

Since learning Go so many years ago it influenced how I build things in every language much in the way this article is espousing. I MUCH prefer functions that

Since learning Go so many years ago it influenced how I build things in every language much in the way this article is espousing. I MUCH prefer functions that take some kind of type/interface/protocol over methods on objects. I committed many sins in my past in Python with mixins that added functionality before I understood how to use Zope Interface and with Go it all finally clicked for me. I don't think any pattern is Right all the time but inversion of control and interfaces rarely bite me to the same degree other patterns have.

thomascgalvin 3y ago
I have also moved towards "dumb data objects", immutable if possible, and a library of functions that operate on them. Exactly what this looks like will obviously depend on the language, though. In Java, I might have a Foo object and a FooController. In Kotlin, I'd probably have a Foo object and a FooController file, but that file would contain functions, not a controller object. Of course, in the bytecode this would map to a FooControllerKt object. Kotlin also offers extension functions, which are similar to how Go declares object methods. I use these for utility functions, as opposed to business logic. If I wanted a function to camel-case a string, for example, I'd use an extension function. If I wanted a function to determine if a string is a valid zip code, I'd use a method that takes in a string.
- brabel 3y ago
  In Kotlin and Dart, the better way to do it is extension functions. Just having free functions that take your data object as arguments is almost the same, but has the huge disadvantage that looking up which functions you can call on the object is much harder.
LinXitoW 3y ago
The biggest issue with that is autocompletion in IDEs. I agree that it's nicer "ideologically", but being able to just go "I got this thing, what can I do with it?" with a simple dot is really nice. Maybe LSPs will at some point be easy to query for that.
- leetrout 3y ago
  At least a portion of that is covered with well structured modules.
deleted 3y ago
[deleted]

thomascgalvin 3y ago

I have also moved towards "dumb data objects", immutable if possible, and a library of functions that operate on them. Exactly what this looks like will obviously depend on the language, though. In Java, I might have a Foo object and a FooController. In Kotlin, I'd probably have a Foo object and a FooController file, but that file would contain functions, not a controller object. Of course, in the bytecode this would map to a FooControllerKt object. Kotlin also offers extension functions, which are similar to how Go declares object methods. I use these for utility functions, as opposed to business logic. If I wanted a function to camel-case a string, for example, I'd use an extension function. If I wanted a function to determine if a string is a valid zip code, I'd use a method that takes in a string.

brabel 3y ago
In Kotlin and Dart, the better way to do it is extension functions. Just having free functions that take your data object as arguments is almost the same, but has the huge disadvantage that looking up which functions you can call on the object is much harder.

LinXitoW 3y ago

The biggest issue with that is autocompletion in IDEs. I agree that it's nicer "ideologically", but being able to just go "I got this thing, what can I do with it?" with a simple dot is really nice. Maybe LSPs will at some point be easy to query for that.

leetrout 3y ago
At least a portion of that is covered with well structured modules.

deleted 3y ago

[deleted]