Re: Some notes after my first PureBasic experience
Posted: Wed Nov 25, 2015 7:10 am
I wish to clarify what I think about OOP (maybe this time I'll be able to write my thoughts in english 100% correctly 
) - if using full OOP everywhere, it is very bad. One class inherits another random class which calls some unknown method of other unknown class which calls another class which inherits one more class referenced to 5 more classes, and you getting such a bullshit as result that you only can write you code once and forget about it, cause you'll never more remind or understand how exactly it all works, not even saying about tries to debug it.
But there is another way, implemented in MS Visual Basic.
VB offers 3 main file types used in projects:
.bas - regular files with source code, called "modules". thats like regular ".pb" files
.frm - forms, they have some restrictions but also used for code
.cls - very-very restricted kind of "classes", called "Class Module"
Those .cls are that what I understand as basic and useful level of OOP support, which gives enough advantages, but don't makes so much problems and not causes brain deformation like full OOP usage does in C++.
In other words, those classes in VB6 are exactly just like modules in PB, but they also allow to dynamically create and destroy multiple instances of them each separated from others.
So:
- If you define module Test in PB and need 2 samples of it, you must define Test2 with the same code and stucture or do something other which smells and looks bad taking an inordinate amount of lines
- but after defining class module Test in VB-style, you later just using keyword like "new" to create and use as many separated samples of Test as you want
Over the years I convinced that such minimalistic level of OOP is "enough for all" (I can't describe all the rules of how it works, anyway it is very limited and not allows doing any stupid or confusing OOP mess) and the system MS used in VB6 is just perfect and working perfectly with procedural paradigm also (VB6 is [or was] first of all procedural language with set of low-level abilities which may be accessed using hacks of it runtime library).
That oop system is what I mean when saying about "connecting OOP and procedures".
@Fred, it is interesting what do you thing about such concept of "class modules"? ( of course if you even read this thread after 4 pages of some weird posts
)
) - if using full OOP everywhere, it is very bad. One class inherits another random class which calls some unknown method of other unknown class which calls another class which inherits one more class referenced to 5 more classes, and you getting such a bullshit as result that you only can write you code once and forget about it, cause you'll never more remind or understand how exactly it all works, not even saying about tries to debug it.But there is another way, implemented in MS Visual Basic.
VB offers 3 main file types used in projects:
.bas - regular files with source code, called "modules". thats like regular ".pb" files
.frm - forms, they have some restrictions but also used for code
.cls - very-very restricted kind of "classes", called "Class Module"
Those .cls are that what I understand as basic and useful level of OOP support, which gives enough advantages, but don't makes so much problems and not causes brain deformation like full OOP usage does in C++.
In other words, those classes in VB6 are exactly just like modules in PB, but they also allow to dynamically create and destroy multiple instances of them each separated from others.
So:
- If you define module Test in PB and need 2 samples of it, you must define Test2 with the same code and stucture or do something other which smells and looks bad taking an inordinate amount of lines
- but after defining class module Test in VB-style, you later just using keyword like "new" to create and use as many separated samples of Test as you want
Over the years I convinced that such minimalistic level of OOP is "enough for all" (I can't describe all the rules of how it works, anyway it is very limited and not allows doing any stupid or confusing OOP mess) and the system MS used in VB6 is just perfect and working perfectly with procedural paradigm also (VB6 is [or was] first of all procedural language with set of low-level abilities which may be accessed using hacks of it runtime library).
That oop system is what I mean when saying about "connecting OOP and procedures".
@Fred, it is interesting what do you thing about such concept of "class modules"? ( of course if you even read this thread after 4 pages of some weird posts
)