A question for OOP experts. - page 20
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Trust me, your codes will die with you too. Do you think anyone wants them?) Well, think.
I didn't post the open code to be parsed. It was a codebase requirement. The main purpose was to post a useful result.
Where?
Where?
How much harder would access be? I have a global kernel that can be seen from everywhere. In OOP I would have to give it up. How to work with elements in windows then? I get comatose when I try to imagine it.))
The biggest truth of this thread is in this post. Indeed, the area of Peter's brain through which he would be able to understand the PLO is in a comatose state, so there will be all sorts of dancing around and around, all sorts of twists and turns... but nothing to do with the PLO.
If you like poetry, I can rhyme. ))
That's my point exactly.
And yet hope was so close...
That's it, I'm off to learn OOP.
And yet hope was so close...
And in his best tradition, Peter reduced everything to the fact that he is the only one of all the one's. Everyone else is not one.
It's as simple as that. After "...That's it, I'm off to learn OOP...", nothing popped into my head...
Alas, exclusionary. A global kernel implies global visibility, which removes the need for
(1)In encapsulating code. Why, when everything is accessible from anywhere?
(2) Overloading of functions. Why when it's easier to do the work in one, making the results universally visible and accessible?
(3)Polymorphism. Why hide different implementations under one template, when one unit can do the work of those template variants? The amount of code would be less and the syntax would be many times simpler.
The whole point of OOP lies in the following:
1. Offloading of human memory. (It is badly offloaded. There is too much syntax).
2. Distribution of common work within a team (everyone knows a piece of code, hence there will be problems of building and debugging).
3. Code portability. (This is really a plus).
4. Marketing. Distribution and sale of development environments, libraries, through advertising of various gimmicks.
Taki finally learn that your "kernel-engine" is a cheesy surrogate of OOP.
It's as simple as that. After "...That's it, I'm off to learn OOP...", nothing popped into my head...
And in his best tradition, Peter has reduced everything to the fact that he is the only one of all the ones. Everyone else is not one.
1. I went to learn OOP so as not to sit in a puddle in front of investors. At the same time, investors were not interested in my knowledge of OOP, but in the results achieved by my approach.
2. Grow out of this kindergarten, with the transition to personalities.