Ya know the more I reflect on the languages I know the more I realize that outside of functional languages none of them really handle immutability well.

Consider that you want most of your objects to be immutable most of the time. Thats all well and good till you realize you want to be able to edit the objects in such a way that it creates duplicates that have some data changed but are likewise immutable.

This tends to stop working, almost entierly, once you get into subclassing. If you parent class has a method that returns a copy of itself with some data modified, this will break in children classes, since you want children classes to return instances of itself, not its parent.

Its not that you cant fix that, but the code gets very ugly very quickly. Generally you are forced to let the code handling the classes do the copying and editing itself, but that is pretty ugly too.

I have had this pattern problem in almost every OO language i messed with, Java, Ruby, Python, etc.

Follow

@freemo Yes, agreed. I've adopted a different mindset to classes; only use for very specific cases, plain functions are better.

@modrobert Im not sure i agree there either. Non-oo coding becomes a mess unless you employ class-like organization (structs or something) in which case your right back to the same immutability/mutability problem

@freemo I think you need to get out of that mindset.

@modrobert I dunno I do a ton of C and other non-OO languages and its usually a nightmare for complex systems... Works fine for simple and straight forward stuff though. But I usually work on the more complex stuff where it just wont cut it.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.