PureBasic Forums - English

1. Statements:
Keyword 'Global' is not really useful.

Solution:
'Global' and 'Shared' means the same.
PB4.x should change the use restriction of keyword 'Shared'.
(Not only allow to use in procedures).

2. Statements:
I miss a C++ like 'private' variable type.

Solution:
PB has a 'private' like keyword: 'Protected'
PB4.x should change the use restriction of keyword 'Protected'.
(Not only allow to use in procedures).

> Keyword 'Global' is not really useful.

Speak for yourself. I find it extremely useful.

If you wanted to use Shared only, for a variable such as appname$, then you'd
need to put "Shared appname$" inside EVERY procedure of your app. Do you
really want all that hassle?

PB wrote:> Keyword 'Global' is not really useful.

Speak for yourself.
1)I find it extremely useful.

2) If you wanted to use Shared only, for a variable such as appname$, then you'd
need to put "Shared appname$" inside EVERY procedure of your app. Do you
really want all that hassle?

Fine! You give me the right questions;-)

1)
If you use Global very often (You like it?) it seems to be a bad design of your code.
And of course I want only the same keyword for the same things.

2)
The only reason for 'sharing' a variable is to change the scope of this variable.
Tell my why I need to sharing all variables inside every procedure?

For me, Shared is useless.

All my global variables are global and all my local variables are protected (overrides the globals).

This works well and I don't think it's bad design. If you use top-level variables that are not Global then you need to have code outside a procedure to use that variable. Now that's what I call bad design.

Or you could, as PB said, use Shared inside every procedure where you use that variable. That's not bad design but it's a lot of extra code.

IceSoft wrote:Keyword 'Global' is not really useful.

I must admit, lately in my coding I've moved from using Global to Shared. I recall reading an enlightening posting >here< about this issue. I got the impression that having top-level variables (i.e. vars defined above or outside your procedures) and declaring shared within only the procedures that 'needed to know' about these variables, reinforced (to me at least) that these shared variables tended to self-document 'what was being used where' (i.e. forces you to remember what variables are needed in the appropriate places, rather than the blanket approach of using global). Having said that, I can understand the approach of Global vs Shared might be a very personal thing in PB programming.

> If you use Global very often (You like it?) it seems to be a bad design of your code

No it's not. I use it for variables that NEVER change, such as appname$ that
holds the name of the running exe. What's the bad design about that? How
would making it non-global, but using "Shared appname$" in every procedure
where I need it, make it a better design? All I see is extra typing for no reason.

> Tell my why I need to sharing all variables inside every procedure?

In every procedure that needs the shared variable, that is. Using Global is a
way to "set and forget" a variable -- so that you know it'll be recognized in
every procedure without having to "Share" it first. It's a time-saver I guess.

I personally like to use Sturctures declared as gloabl or sometimes global Linked Lists for Backend information needed in many places of the application for example for Userlists in a Messenger or for styling information of message windows which are the same for every window so I save them in a global structure. It's also very handy for stroing settings. So I use a global sturucture for all settings. At the beginning oif the program I load it from the ini and everywhere settings are changed I change them in the structure and than call a procedure wich dumps the whole structure to the settings.ini that tends to be really effective and easy to manage.

lol - leave Global alone!

For that matter, leave all the definition type keywords alone!

Invent some others if you want, but don't mess with the existing!




We want globals!
Whendowewantthem?
NOW!



Edit: In any case it seems strange to want to change the behaviour of Shared so that it acts like Global and then invent another keyword to behave like Shared. Or did I miss some critical point.

IceSoft wrote:If you use Global very often (You like it?) it seems to be a bad design of your code.

Yes, that's me. Not only very often, but more !
I am a very bad programmer

I use Global as well and love it

ps I like to stucture but find it hard to keep tidy 'Programs seem to have a life of thier own '

For heavyly threaded apps, global is more than helpful.
You should learn that if our code is messy, you are not affected; if there is function you don't use, you are still not affected... If you wanna delete functions we use, we are affected (& pretty badly).

I have found shared useless as well. For instance, when I want to pass a Shared variable from one procedure to another, I cannot do that with Shared variables. With globals, I can access them directly.

Hi Shannara.

Um, not useless - just not useful to you and your way of coding. Putting things one way implies PB sucks, the other implies your approach has no use for them (more accurate).

Having said that, I also tend not to use shared. The scope of variables in my main flow are either limited to main or declared Global.

AND .. for the Global knockers ..

.. using Global does not a bad programmer make!

Writing unsupportable and unfathomable software is bad programming, the rest is approach. There can be bad use of globals (and other things) and there can be contorted code written to get around situations that cry out for globals (or other maligned practices).

(Taking on everyone!) (I'm in a feisty and frisky mood)

> (Taking on everyone!) (I'm in a feisty and frisky mood)

Wanna take me on?

I'm game.