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! ....
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.
Ре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.
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.
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.
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?".
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.
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.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
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.
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)).