Another bit o' info about avoiding globals. Imagine you're creating a pinball game using globals. You have global variables like BallX, BallY, BallSpeed, BallAngle, BallRadius, BallImage, LevelWidth, LevelHeight, LevelMap, Score, Highscore, Lives, etc. etc.
All nice, the game works. And then suddenly you want to make a 2-player option where you'd have 2 of such pinball machines next to eachother. It would mean you need all those global variables twice. What could you do? Make 'em an array of 2? Could be, but those variables are everywhere, it's quite tiresome to run through the whole code to fix things.
OO?
You'd have all those varibles in a pinballmachine type, and then simply:
Player1machine:TPinball=New TPinball
Player2machine:TPinball=New TPinball
or
Local Player:TPinball[2]
Player[0]=New TPinball
Player[1]=New TPinball
That's far more easier than to manually change all those variables.. and this is actually a very simple example.
Ofcourse, do you need Bmax for this? Of course not, I was doing this in B+ already with banks, but instead of "Player1.shootball" I'd be doing "shootball Player1".
The problem with globals is the sheer lack of namespace you'll run into, sooner than you'd hope. If you have a lot of different 'objects' and they're all destined to use globals, then you either get cross references, or you're really cooking some extravagant names.
Another nice one, imagine you'd be making your own gadgets (knobs, sliders, buttons, etc.). If you would be doing this without OO and with global functions, then you'd get stuff like: UpdateKnob MyKnob, UpdateSlider MySlider, UpdateButton MyButton. While not the end of the world, it's still some typing work.
When doing OO, an update method is part of such a gadget. So it'll be MyKnob.update, MySlider.update, MyButton.update. What you gain is that you loose those global functions. Within the type (e.g. in some method of 'Slider') you only need to type 'update', that's what you do most of the time anyway: updating from within the object.
About namespace, when still doing the non-OO way and use global functions, it could very well be that you could commit yourself to names you're aware of so that you will avoid nameclashes yourself. If you keep some guidelines this could very well possible, since *you* are the one who's managing the whole shebang.
And now you want to use library x from coder y (since it's such a good library from a respective coder) .. now all of a sudden you don't control your own sources anymore since it has external code, which is usually quite hard to read. (at least it is for me!) If it's such a respective coder then you're lucky since all the stuff would prolly be tucked away in types, just as I wrote above. But what if the library is good, but not very cleverly written? What if you were using some UpdateKnob function, but the coder of that lib does so too (for a whole different reason/situation of course)? Here you see the benefits of datahiding. You can hide zillions of variables and methods into a class. Without OO you'd have zillions of variables and functions all being global and all being around messing up with whatever comes next -which you can't always know!-.
So, what globals are allowed? Well, depending on the scale of your app there are perhaps some. Perhaps -for a game- having variables such as gamewidth and gameheight as a global seem obvious, but is it? In most cases it'll do.. but what if you want to run multiple instances of the game in multiple windows, each with its own size? True, perhaps not a realistic example, but technically it's a perfect example. If you store gamewidth and gameheight in your game type then you can do this. When you make 'em globals, then you can't.. (unless you make 'em an array orso)
All nice, the game works. And then suddenly you want to make a 2-player option where you'd have 2 of such pinball machines next to eachother. It would mean you need all those global variables twice. What could you do? Make 'em an array of 2? Could be, but those variables are everywhere, it's quite tiresome to run through the whole code to fix things.
OO?
You'd have all those varibles in a pinballmachine type, and then simply:
Player1machine:TPinball=New TPinball
Player2machine:TPinball=New TPinball
or
Local Player:TPinball[2]
Player[0]=New TPinball
Player[1]=New TPinball
That's far more easier than to manually change all those variables.. and this is actually a very simple example.
Ofcourse, do you need Bmax for this? Of course not, I was doing this in B+ already with banks, but instead of "Player1.shootball" I'd be doing "shootball Player1".
The problem with globals is the sheer lack of namespace you'll run into, sooner than you'd hope. If you have a lot of different 'objects' and they're all destined to use globals, then you either get cross references, or you're really cooking some extravagant names.
Another nice one, imagine you'd be making your own gadgets (knobs, sliders, buttons, etc.). If you would be doing this without OO and with global functions, then you'd get stuff like: UpdateKnob MyKnob, UpdateSlider MySlider, UpdateButton MyButton. While not the end of the world, it's still some typing work.
When doing OO, an update method is part of such a gadget. So it'll be MyKnob.update, MySlider.update, MyButton.update. What you gain is that you loose those global functions. Within the type (e.g. in some method of 'Slider') you only need to type 'update', that's what you do most of the time anyway: updating from within the object.
About namespace, when still doing the non-OO way and use global functions, it could very well be that you could commit yourself to names you're aware of so that you will avoid nameclashes yourself. If you keep some guidelines this could very well possible, since *you* are the one who's managing the whole shebang.
And now you want to use library x from coder y (since it's such a good library from a respective coder) .. now all of a sudden you don't control your own sources anymore since it has external code, which is usually quite hard to read. (at least it is for me!) If it's such a respective coder then you're lucky since all the stuff would prolly be tucked away in types, just as I wrote above. But what if the library is good, but not very cleverly written? What if you were using some UpdateKnob function, but the coder of that lib does so too (for a whole different reason/situation of course)? Here you see the benefits of datahiding. You can hide zillions of variables and methods into a class. Without OO you'd have zillions of variables and functions all being global and all being around messing up with whatever comes next -which you can't always know!-.
So, what globals are allowed? Well, depending on the scale of your app there are perhaps some. Perhaps -for a game- having variables such as gamewidth and gameheight as a global seem obvious, but is it? In most cases it'll do.. but what if you want to run multiple instances of the game in multiple windows, each with its own size? True, perhaps not a realistic example, but technically it's a perfect example. If you store gamewidth and gameheight in your game type then you can do this. When you make 'em globals, then you can't.. (unless you make 'em an array orso)