Due to potential new direction of D, I’m looking for some escape route just in case. I’m primarily a gamedev, so no functional programming languages like Rust or Haskell. Also one of the features I dislike the most in C/C++ is the super slow and super obsolete precompiler with its header files, so no zig, I don’t want to open two files for editing the same class/struct. Memory safety is nice to have, but not a requirement, at worst case scenario I’ll just create struct SafeArray<Type>. Also I need optional OOP features instead of reinventing OOP with all kinds of hacks many do when I would need it.

Yes I know about OpenD, and could be a candidate for such things, just looking into alternatives.

  • ZILtoid1991@lemmy.worldOP
    21·
    3 months ago

    Classes can be useful for abstraction. Just because they often overused doesn’t mean they’re bad.

    Without an explicit class, I would either:

    • had to reimplement them in a language without them (which looks extremely ugly and can be unsafe),
    • create an “omnistruct” that keeps track of all posssible field (only looks a bit ugly),
    • use uglier virtual functions for cases when I would need local states (doStuff(cast(void*)&localstate, values) vs localstate.doStuff(values)).

    While structured programming was a godsend to the chaos preceding it, newer programming paradigms should have been instead seen as tools rather than the next dogma. OOP got its bad name from languages that disallowed its users to develop without classes, and enterprise settings making its devs to implement things that could have been simple functions as classes, sometimes complete with factories.

    Same is with functional programming. There’s clearly a usecase for it, but isn’t a Swiss-army knife solution for all problems of programming.

    • MajorHavoc@programming.dev
      3·
      3 months ago

      Well said.

      Here I am trying to wind people up and you’re responding with thoughtful nuanced consideration.

      You make some great points.

      I’ll add - for folks reading along - I do think a class is still almost always an anti-pattern, even with all the OOP class function and factory pattern stuff removed.

      I also feel (as you referenced):

      • Functions being forced to reside inside objects is just stupid.
      • Factory patterns are horrible, because they mix config into program code, maximizing uncertainty when debugging

      And also:

      • Inheritance is almost always a worse idea than an interface.
      • classes tend to have additional fancy tooling to make it easier to carry state data around - which is usually a bad idea

      State data is a necessary evil in most programs.

      I’ve found that most advanced class object implementations treat program state data more like a pet than a threat.

      Sorry for the long response - I know you don’t need it - you know what kind of tool you’re looking for.

      I figure they extra detail above might provide food for thought for folks reading along who are surprised there’s even contrasting opinions on classes.

      (And I feel a little bad for not really posting anything very useful earlier in the thread.)

    • BatmanAoD@programming.dev
      2·
      3 months ago

      You don’t need to do any of those things with Go or Rust. Interfaces/traits provide the capability for dynamic dispatch.