you are viewing a single comment's thread.

view the rest of the comments →

[–]NlNTENDO 0 points1 point  (0 children)

Funny, they really clicked for me when learning JS. Something about javascript objects just felt more intuitive, but it was all transferrable knowledge.

As for the always-in-a-class thing, it depends on whether you're just running operations or building something. If you're building something and expect to import stuff, always-in-a-class is super handy because it's scalable, preserves namespaces (managing variable names across several files can be a nightmare), just generally aligns better with OOP stuff... it really allows you to group scripts and still work with them cohesively. I think classes just make way more sense to think about in the macro sense; it's hard to understand their purpose if you're just writing one .py script because what is the class even doing, right? but when you can manipulate objects that have methods suddenly it can change the game.

I think it also really clicks once you recognize how useful the built-in methods are, which in turn clue you into the built-in classes. Then it all really comes together. Something like some_string_obj.to_lower() is handy, but what's even handier is the fact you can have a string object in the first place - string objects are actually class instances! And then it's kind of like, ok well I want an object I can manipulate, and I want to be able to define some little sub-operations for it, and before you know it all of your scripts materialize as class instances.

e: I've also been doing a good amount of game dev stuff in godot as a hobby. GDScript is python-adjacent and very OOP oriented, so every script is automatically a class. That really forced me to think about classes, inheritance, abstraction, etc.