On Friday, 24 June 2022 at 14:30:05 UTC, ryuukk_ wrote:
> What's your use case? without this answer, object has no meaning
Sure, although I guess forkit means that we cannot avoid modelling in terms of objects (or classes) as the human brain is essentially a rather slow abstraction machine that to a large extent has a tendency to create broad sterotypes of what is needed to understand the real world (or in the case of simulation or game, a fictional world). Stereotypes ≈ classes.
> Programming computers have no concept of "objects", it is pure programmer's religion, something sold by scholars and forgotten companies to produce cheap engineers
I would rather say, whenever you encapsulate something you have a defacto object.
Even in a relational database you have entities, which are corresponding to objects (you can also group them as classes). Those table entries for entities (keys) are defacto object representations.
I don't see a contradiction between object-oriented-modelling, component-based-modelling or entity-relationship modelling, I view it as facets of the same. You can mix. The more modelling knowledge you have, the more cogntitive aids you have, the more likely you are to arrive at a good model. Then you can choose an implementation strategy that suits your use case (one important decision factor is whether you believe that the model has to change later or not).
What is certain is that you need a model of the world you want to represent, be it the real world or a gaming world. And a strategy to represent it your chosen language/database.
> Unity is back to data oriented design because "objects" was found to be inefficient
Ok, so when you design a framework for others to use, and don't want them to know the inner workings of the framework, then you are willing to pay a rather high efficiency price to begin with. OO-models do not require you to put everything in the same record though. You can split off physics in a game from avatar and soforth.
Also, component based design, which decouples entities by giving them identities (e.g. a number) instead of using the address, has some advantages over using pointers; you can more easily split the system and distribute it over many computers for instance. And if you create many similar systems, then it can make some reuse cases easier as you only deal with an integer-id. But it has a price. In terms of efficiency it can become worse or it can become better… it all depends on wether the decoupling makes sense or not.
But the key point is that you don't have to choose between classic OO implementation or components. You can mix.
> D doesn't need them, metaprogramming, struct, function is all we need, it's our strength, and we should capitalize on that, and show the world that if they need alternative to "objects, they can find the right tools with D!
Well, but surely structs would be more intuitive to use if they could inherit rather than using alias this? Even if you never go further than one level of inheritance, it is still beneficial. E.g. have one abstract Node struct that takes care of book-keeping and a bunch of structs that inherit from the Node that does the real work that your game cares about. Many ADT implementations use this strategy, and it is OOP. You can use other strategies, but they tend to become clunky and/or verbose.
(I would also argue that template composition can be viewed as a form of object-model implementation, btw)
> Instead of sticking to C# or coming up with a new language HPC# and a new compiler "Burst", Unity should have picked D long time ago, i still try to lobby for them to add support for proper C FFI, so we can properly use D there, but it's hard..
Unity sound like fun, I don't know much about it, unfortunately. But I agree that it sounds better to build a game with D than C#.