I lived in a perfect OOP bubble for my entire life. Everything was peaceful and it worked perfectly. When I wanted to move that player, I do player.move(10.0, 0.0); When I want to collect a coin, I go GameMan -> collect_coin(); And when I really need a global method, so be it. I love my C++, I love my python and yes, I also love my GDScript (Godot Game Engine). They all work with classes and objects and it all works perfectly for me.
But oh no! I wanted to learn Rust recently and I really liked how values are non-mutable by defualt and such, but it doesn't have classes!? What's going on? How do you even move a player? Do you just HAVE to have a global method for everything? like
move_player();
rotate_player();
player_collect_coin();
But no! Even worse! How do you even know which player is meant? Do you just HAVE to pass the player (which is a struct probably) like this?
move(player);
rotate(player);
collect_coin(player, coin);
I do not want to live in a world where everything has to be global! I want my data to be organized and to be able to call my methods WHERE I need them, not where they just lie there, waiting to be used in the global scope.
So please, dear C, Rust and... other non OOP language users! Tell me, what makes you stay with these languages? And what is that coding style even called? Is that the "pure functional style" I heard about some time?
Also what text editor do you use (non judgemental)? Vim user here
C programmer here. I can't code in Rust and although I do have some interest in learning it, C is still the best one to me. Probably not the best way to do it, but I'd do something like this (based on the code in your ss):
I would probably move the struct
Player
and the functionsplayer_new
,player_move
andplayer_rotate
to another file (likeplayer.c
or sth), I'd create its respective header file with the definitions of each thing and with that I basically created a simple interface to create and handle players without needing OOP. English is not my native language, so I'm not really sure about what's the name of the programming paradigm used in C (which definitely is not OOP), but in my native language we call it "programación estructurada", which in English would be something like "structured programming".Tbh I code in both non-OOP and OOP languages (most of the time C, JS and Python) and to me both paradigms are just fine. You can pretty much do anything in either, but each of them might work better for you on different situations and depending on your needs. I also use Vim btw.
@autumn64@lemmy.blahaj.zone
Eso en C se llama TDA (tipos de datos abstractos) creas una estructura que contiene los datos y luego un "set" de funciones que manejan todo lo de esa estructura. Es como un cuasi OO en C. La estructura tiene los atributos y las funciones específicas para esa estructura serían los métodos.
@Smorty @autumn64@mast.lat
I'm sorry but this is effectively just OOP but worse.
You're still defining methods of the player class here but the referenced object/struct is explicit rather than implicit. Contrary to languages that properly support OOP though, they're entirely separated from each other and entirely separate from the data type they effectively represent methods of as far as the language is concerned. They only share an implicit "namespace" using the
player_
function name prefix convention which is up for humans to interpret and continue.There's still quite a few software written in C that does exactly as I did though. Look at OpenSSL's EVP library. I'm not sure about what you mean by "OOP but worse", wouldn't everything be worse than OOP since C isn't an OOP language? Anyways. As I said, what I did is way more common than it seems at least in C, so I get your point but still I can't seem to be able to see what's inherently wrong with it. I would appreciate if you shared any better ideas you might have, though!
Oh, absolutely.
I meant specifically this pattern you showed; it's object-oriented programming but in a language that does nothing to support it.
Rust isn't an OO language either but it adds some sensible abstractions to make OOP-like programming possible in an immediately recognisable and standardised manner.
My primary problem is that it's convention rather than rule.
Just don't use C if you can avoid it ;)
I agree, and thus I think it's safe to assume we also hate the lack of encapsulation in Python despite technically being an OOP language.
I'm fine with C, and if I stop coding in C I would starve since my job depends on it, still thanks for the suggestion though! ;)