Restricting the scope of identifiers

[Little John]

Hi all,

I'd like to ask whether there is interest in being able to restrict the scope of identifiers. This would help to achieve better modularity, which is especially useful for source code libraries. Maybe we come up with some useful ideas, which I can implement in my LPP pre-processor.

For instance, for developers of libraries I could introduce a new keyword say Local, in order to declare variables that have a scope similar to Global but which are only visible in the file where they are declared. Another option is to introduce namespaces that can be applied by users of libraries, like

Code: Select all

XIncludeFile "calc.pbi" As math

Debug math\Sin(0.5)

What do you think, and what are you missing in this regard?

Regards, Little John

[Mistrel]

Please move this to feature requests. I agree that this would help make code much more modular!

[Little John]

Please move this to feature requests. I agree that this would help make code much more modular!

There have been feature request concerning this topic in the past.
However, this thread is not a feature request. Please read carefully what I wrote.

Regards, Little John

[alokdube]

is it such a big deal naming variables as filename.variable?
i mean most of the times the includes are procedures etc so the variables there can anyways have their own scope

[Mistrel]

Little John's suggestion is advantageous because it allows for polymorphism by restricting scope. Simply renaming each function would also work but it would not be possible to have two functions of the same name with different functionality, which can lead to complex naming schemes between source files to prevent collisions.

For example, both File1 and File2 inherit from File3 which has the function Send(). With his method of encapsulation both File1 and File2 can choose to inherit Send() from File3 or create their own. So, when File4 imports File1 and File2 each can have independent functionality for Send().

[alokdube]

well the Perl mechanism of module::function() is always there, but I never was an OO Fan....
Most of the times, It is simpler to rename the parent function as filename_function() if that be the case rather than letting the compiler handle it...

personally when debugging includes , I like to cut paste the includes into the parent file itself if possible because it all becomes "clear".....

[alokdube]

take this code snippet from a card game

Code: Select all

#NumPlayers=8; number of players
#DEBUG =0;set to one for debug
#Port=6666
#MinPlayersperGame=2
Global Actual_players=0 ; keeps track of number of players actually present
Global GameCredits=1;credits per move in this game, i.e. the credits deducted from the player
Global game_on=0;becomes 1 when the game is on
Global show_allowed=0; becomes 1 when a show is allowed in the game
Global show_called=0 ; this value becomes 1 when a "show" is called in the game
Global players_in_game=0;keeps track of people playing the game
Global Winner$="" ;holds the name of the winner of the game
Global total_credits_in_game=0;holds the total credits on the table in this game, the winner takes this
Global Winner_reason$="";holds the reason why Winner$ has won

Structure Player_data
Name.s
;"null" implies no player at this position
Status.s 
;"seen" if user has seen cards, "pack" if user has packed
;"" if user is new (no cards so far) and "blind" is user is blind.
Credits.l
ClientID.l
DomainName.s
EndStructure

Global ServerEvent
Global firsttomove_player_id=0
Global playertomove_id=0

Global Dim PlayerInfo.Player_data(#NumPlayers-1)




IncludeFile "3-patti-engine.pbi"

The include file looks like:

Code: Select all

Global Dim Suite.S(3) ; string val of suite
Global Dim CardFace.S(12) ; string val of cards

Global dealt ;keeps track of how many cards are dealt
Global  Trio_winner=-1 ; this holds the value of a trio winner -1 indicates no trio
Global  Trio_count=0 ; this holds the number of people with trios
Global Sequence_winner=-1 ; holds the value of the sequence winner -1 indicates no sequence
Global Sequence_count=0 ; this holds the number of people with a sequence
Global Sequence_color_count=0 ; this tracks if we have a sequence and color
Global Sequence_color_winner=-1 ; this tracks the sequence color winner
Global Color_winner=-1 ;this holds the color winner
Global Color_count=0; this tracks the number of people with a color
Global Pair_count=0 ; holds track of number of people with a pair
Global Pair_winner=-1 ;holds the pair winner
Global Highest_winner=-1 ;holds the highest card winner
Global Highest_count=0 ;holds highest count


; a card is defined as card\suite , card\cardface
Structure Card
suite.b
cardface.b
EndStructure

Global Dim Player.Card(#NumPlayers-1,2)
;2D array of cards of the form Player(player,card)\suite and Player(player,card)\cardface

Global Dim Dealt(51)

Obviously in the scope of the code, just because the functions were coded seperately, I defined globals seperately but they could all be clubbed into the main file and let the includes handle procedures...the good old C/ANSI BASIC way...