Representation of an object in programming.

[Реter Konow]

This topic will be of interest to those who are preoccupied with global programming issues.

The question that's bugging me is "why is the well-known Object model in the standard OOP concept canon?". I mean, an Object is an entity that people describe in words every time they say the word. With the advent of programming, an attempt to describe the Object by code was logically connected and a special technology was invented to do it, but here's the question: why just one? As if the first language completely superseded the others and did not let them evolve. This is impossible in ancient times, but possible in the age of globalism and propaganda. And so it happened - one representation of the Object conquered the world and blocked the directions of other ideas.

I would have accepted the standard conception of the Object long ago, if I (as a philosopher) had not had some complaints about it.

1. First of all, a preface: An evolutionary step in programming was taken when the main thesis was stated - programming takes "objects" as a basis and any program should logically break into them. That is, we no longer write algorithms (sequences of operations), but create "entities". Algorithms, on the other hand, we put in their structure so that they become part of an overall "ensemble" of interactions. Why? - It's more efficient that way. BUT, here's the question: where is the "officially registered" philosophical concept of the Object? Alas, none exists to this day, nor can there be.

This means that the authors of the OOP concept acted arbitrarily, relying on the "infallibility" of their philosophical notions.

2. Here, are some of my claims:

(1) Why doesn't the standard concept have a tool " The state of"? Don't objects have states? A state can be described in a structure, but this is inconvenient. The standard concept isn't designed for working with object states. For example: I create a special structure, list object's parameters, copy a part of it (selected parameters), name this part as a state and write values which correspond to some state of the object. Then I connect it to the main structure of the object.

(2) There is no instrument of"event". I mean, an Event "hovers" in the standard concept, but it cannot be described as an enumeration, class or function. A simple description of an event in programming would come in handy. For example: describe it as a structure, but in it point to "background" states of environment and objects, and point to a key change, which is the trigger to start a chain of other changes. Again - OOP is not sharpened for concise event description and offers to describe them in a bunch of conditions, which have no name and are located "anywhere".

(3) Further, a parameter is not an independent object. In fact - it is the most important object, which can be templated and any system can be assembled from its copies and modifications. It doesn't...

I could go on and on, but my message is clear: build your OOP and maybe you will invent something much cooler, because no one tried to do it seriously before you. And the standard concept is a subjective vision, not physics or mathematics and it can be modified)).

[Andrei Trukhanovich]

there is a design pattern called state

there is an observer pattern

there's the bicycle pattern. it's peter's favourite pattern.

[Igor Makanu]

both C# and Delphi have propertieshttps://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/properties

and ewents aren't a gimmick for a long time

but, in my opinion, another topic on the words of a rather good song "Fairy" - YazheVik .... You go and I'm a fairy! ....

[transcendreamer]

Generally speaking, when defining the Object, one must also define the Subject, otherwise this is an incomplete description of the world, besides in more modern philosophical concepts there is the Traject with an independent relationological status as an intermediate/bonding link between the Object and the Subject.

[Dmitry Fedoseev]

Peter, coming in from the wrong side again. Why should state be a tool? State was and is, has not gone anywhere, it is even more primal than everything else. And yes - an event is not a state, so it is not described but recorded.

[Dmitry Fedoseev]

Реter Konow:

...but where is the "officially registered" philosophical concept of the Object? Alas, none exists to this day, nor can there be. ...

Because it is not based on philosophy at all. The Object in programming is not something sublime, mystical or anything else you could have imagined. It's simply an amalgamation of functions and variables.

[Vladimir]

Реter Konow:

This topic will be of interest to those who are preoccupied with global programming issues.

I'm wondering, "why is the commonly known Object model in the standard OOP concept a canon?".

Because the first two big O's come first. Since the concept is object-oriented, they are the essence of the concept. In the same way that in procedural programming concept procedures are the main point, in SQL queries are the main point, ignoring how they are executed, and so on and so forth. The essence, not the canon. The canonization of OOP with its opposition to other approaches is actively engaged in this forum, that is why there is such an impression.

[Aleksey Nikolayev]

Instead of reinventing your own bicycle, you should study type theory and practise its application to programming in functional languages (e.g. Haskel).

For an understanding of the philosophical and logical foundations, you can read Bertrand Russell.

[Koldun Zloy]

Реter Konow:

This topic will be of interest to those who are preoccupied with global programming issues.

Blah blah blah.

All this has nothing to do with OOP or programming.

Better call it "How many objects can fit on the tip of a needle?".

[Реter Konow]

Vladimir:

Because there are two capital O's in the first place. Since the concept is object-oriented, they are the main essence of the concept. In the same way as in the procedural programming concept the main point is procedures, in SQL the main point is requests ignoring the way they are executed, etc. etc. The essence, not the canon. The canonization of OOP with its opposition to other approaches is actively engaged in this forum, that is why there is such an impression.

I asked a question: "why is there only one standard for describing and constructing objects"?

You have decided that my question is "why is OOP canon?

Object orientation in programming structures, scales and implements tasks. There is no question about it. But, why is the format the same?

[Реter Konow]

Dmitry Fedoseev:

Because it doesn't rely on philosophy at all. The object in programming is not something lofty or mystical or whatever else you might think of. It's simply an amalgamation of functions and variables.

This is where you can't do without a philosophical concept. Simply merge functions and variables without following a well thought out blueprint of the object? We're given certain tools: classes, structures, access modifiers... but there could be other tools... e.g. state, selection, mapping... why not? My point is that the OOP format and toolkit can have versions...

And in certain cases, a different version of the object description format may be more effective.