Open al1-ce opened 1 month ago
When I started creating Fusion, I wasn't an OOP-fan at all and I wanted to design it like C. I learned the hard way that OOP is actually very useful for a lot of cases.
I think your point is having an option for a C API with no class name prefixes? Wouldn't it make the users coming with C-like library designs instead of OOP ? And an increased risk for name clashes?
Would we allow top-level constants? Global variables? Are functions public
/internal
? (protected
/private
don't seem applicable)
My story is opposite, initially I was a fan of OOP, but I grew more and more fond of procedural programming and strayed away from OOP a lot.
For C-like library desings it depends. Both ways would be valid and you technically could promote OOP desing while also noting ability to do it other way.
Name clashes aren't really a problem if you know what you're doing and if you don't then OOP is best friend!
For constraints functions would probably be public by default since it's usually the case in languages. Global variables is question because most languages allow it and it'd allow easier #if
s for OOP languages, but in low-level languages it's very discouraged. So, probably yes for global variables (just gotta not put then in headers haha).
As title suggests, I think it'd be nice to be able to write code without using classes. It'd be nice for languages which don't strictly have to be encased in classes (basically all except Java and C#).
Either throw a compiler error (easy way) or encase top level functions in class with filename as name (hard way).
Another possibility (combined with compile error if this pattern is missing):
Majority of languages don't strictly require everything to be inside of classes and class-based language promotes certain way of writing API and libraries (i.e builder pattern), being able to mix and match top level functions and classes would allow for greater freedom.