Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> This is primarily because of inheritance, which seems counter-intuitive

I agree that inheritance creates a lot more problems, but the usages of non-static methods and internal state even in classes with no usage of inheritance can feel just as bad, when you have a high level method utilizing instantiated objects. Internal state as a whole can be avoided fairly often



I don’t see much difference between

    some_state.do_stuff()
    do_stuff(some_state)


They're just different syntaxes for the same thing. I think what OP is driving at isn't the syntactic difference but making immutable what doesn't need to be mutable. You could do that with either syntax.


Yes, but I think the person he/she was replying to is right, the biggest problem is inheritance.


The second one scares me. It implies some_state is mutated (or not, we may just be logging something) by the do_stuff function while the first makes it very clear that some_state is in charge of doing stuff and that the implementation is aware of how some_state is implemented itself.

OTOH, the second one would be much better (and imply immutability) if it were written as

  new_state = do_stuff(some_state)
But it'd also allocate a new state.


This is a symtom of seeing everything with the OOP and state glasses.

let's have do_stuff=square and some_state=2.

What does square(2) imply?


Better yet, what does 2.square() imply.


Immutability is independent of whether something is a method call vs a function call.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: