
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
