Exploring the philosophy of objects

[Ola Fosheim Grøstad]

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#.