3 ms·

Is it because you associate methods with statefulness and because you believe statefulness is bad? If so, I'd point out that methods can just be pure functions

Is it because you associate methods with statefulness and because you believe statefulness is bad? If so, I'd point out that methods can just be pure functions and objects can be immutable. Or, more controversially, partial application is just a lazy person's method definition.

pjc50 7y ago
> methods can just be pure functions and objects can be immutable. This is true, but then you start wondering what the data hiding is for, especially if an object has getters for all its immutable members.
danShumway 7y ago
No, I've recently started to mentally separate "functional" and "pure", even though they're often correlated. I've built functional systems that mutate data, and I've built traditionally object-oriented systems that always return new objects on every function call. I think it's more about organization? And more about how often structs in my functional systems evolve over the course of a single function call. Maybe it's that when you're attaching methods to an object, you have a finite number of things you can do to that data. With a struct, I'm always just one `map` (or even a mutation) away from being in a different format that can be consumed by different methods. Of course this can happen with classes as well -- you can have transformation methods, there's nothing technical stopping you from setting up a class system where you're jumping around that much. But I feel like it happens more when I'm doing functional programming. An IDE that was focused on "what methods can consume this data" might not capture that -- I'm not saying it wouldn't occasionally be useful, it's just that "what methods can consume this" is not the first question I ask when I see a struct. All of the methods consume it, I can just transform the data or combine it with another struct to fit whatever format a method requires. > Or, more controversially, partial application is just a lazy person's method definition. I reasonably strongly agree with this.

pjc50 7y ago

> methods can just be pure functions and objects can be immutable. This is true, but then you start wondering what the data hiding is for, especially if an object has getters for all its immutable members.

danShumway 7y ago

No, I've recently started to mentally separate "functional" and "pure", even though they're often correlated. I've built functional systems that mutate data, and I've built traditionally object-oriented systems that always return new objects on every function call. I think it's more about organization? And more about how often structs in my functional systems evolve over the course of a single function call. Maybe it's that when you're attaching methods to an object, you have a finite number of things you can do to that data. With a struct, I'm always just one `map` (or even a mutation) away from being in a different format that can be consumed by different methods. Of course this can happen with classes as well -- you can have transformation methods, there's nothing technical stopping you from setting up a class system where you're jumping around that much. But I feel like it happens more when I'm doing functional programming. An IDE that was focused on "what methods can consume this data" might not capture that -- I'm not saying it wouldn't occasionally be useful, it's just that "what methods can consume this" is not the first question I ask when I see a struct. All of the methods consume it, I can just transform the data or combine it with another struct to fit whatever format a method requires. > Or, more controversially, partial application is just a lazy person's method definition. I reasonably strongly agree with this.