A simple Analogy to help understand namespaces.

[Endless Night]

Here we go this hopefully will help you to biggin to understand namespaces.  Think of namespaces as boxes.

-Imagine you are standing in a huge box that contains all the Variables you can see   %myVar %MyVar2  etc.
- Now imagine that you surrounded by Loads of smaller boxes that have no name and are closed but could hold variables !myvar, !myvar2.
- You also notice that one of the small boxes is open and its called Standard namespace. Its currently empty but could hold variables !myvars  (! not %)  You decide to set one  (set !MyTest standardbox)
-So you grab one of the other small boxs and say i'm gona  have a look inside this box, but i don't want it contents to conflict with my existing ! variables
-So you take the open (standard) small box, close it and push it to the side on a stack of empty boxes (namespace push).
-After stacking your closed box you pickup one of the other small boxes and say thats it i'm gona name this box and open it  (namespace local myboxname)
-After opening it you see their is nothing inside so you decide to put something inside (set !MyTest  testBox)
- Now happy after such achievements you pine for your original small box and think it would be so be great to close this box and pop the last one back open...  (namespace Pop)
- you check you var and low and behold !mytest = standardbox

in code

Code: [Select]

set !myTest standardbox
display ok TestVar: !mytest
namespace push
namespace local TestBox
set !myTest TestBox
display ok TestVar: !mytest  (Im using a different namespace)
namespace pop
display ok TestVar: !mytest   (Back to my original namespace)
display ok SElect Tools from EUO MEnu, do a  var dump $ note you have a serveral !Mytest vars $ one Std (default box) and one from the defined box
halt
After running code to a var dump, tools menu option var dump, scroll all the way to the botton you will see you have 2 MYTest Vars, One in Standard namespace one in TestBox namespace.

!L~STD~MYTEST: Defaultbox
!L~TESTBOX~MYTEST: TestBox


Hope this box analogy helps to explain this mystery.

[Neo]

Hehe, nice way of explaining this, I bet this will help out those who are struggling to understand namespaces...

Great initiative!

[seeriusly]

Thank you EN for taking the time to help.  I tried to wrap my skull around that analogy, but...

Why would I want to use different boxes?

Would i want a box for each sub and name them like you did in your analogy as "namespace local Testbox" (a subs variables) and have "namespace local Testbox2" (another subs variables) ?

I tried to find one of your subs in the public library, so that maybe you might break it down a bit more, and noticed you don't use namespaces in any of them.  lol... 

[UOMaddog]

I always used the idea of a building with a bunch of rooms. Each time you enter a new room (namespace push) you have a new set of stuff in the room. The rooms may be used for any purpose. But every room has windows to the outside (global namespace) that can always been seen (like items outside in your yard). When you namespace pop, you're going back into the previous room that you were in! And each room needs a unique name so you know what to call it, like living room, dining room, den, kitchen, bathroom!

[Neo]

Thank you EN for taking the time to help.  I tried to wrap my skull around that analogy, but...

Why would I want to use different boxes?

Would i want a box for each sub and name them like you did in your analogy as "namespace local Testbox" (a subs variables) and have "namespace local Testbox2" (another subs variables) ?

I tried to find one of your subs in the public library, so that maybe you might break it down a bit more, and noticed you don't use namespaces in any of them.  lol... 

Namespaces are especially good if you have a sub for instance, that you would want to use on several of you scripts, or subs that you wish to share with others, so that they can use in theirs...

For example, let's say you're going to use TM's travel sub... It will take care of recalling/SJ for you... Now, imagine if he would just use standard variables (those represented by a percent sign (%) followed by the name of the variable) instead of using a specific namespace. He could set the runebook id to %runebook for example...

Now let's say you already use that variable %runebook for another runebook somewhere in your script... By using his sub, the %runebook var is going to be changed, and would no longer work for the rest of your script. So, instead of using a standard variable, he will use a namespace variable (starting with !) inside a specific namespace, just for his sub. So, you could use TM's travel sub without having to worry about the name of stuff you would use in your own script...

Don't know if this is clear enough for people to make sense of, but I tried!

[TrailMyx]

Great initiative!

That's why we pay him the big bucks!

[seeriusly]

Okay...  So I guess it's just a way to organize variables. Now...  Might we use a sub of TM's then as example?

Code: [Select]

; %1 = spell number
; %2 = #TARGETID or SELF or NONE
; %3 = retry count (-1 = cast until successful)
; %4 = cast delay
; %5 = recovery delay
sub TM_NewCastSpell
  namespace push
  namespace local NCS
  set !lpc #LPC
  set #LPC 100
  set !whichspell %1
  set !whichtarget %2
  set !castretrymax %3
  set !waitdelay %4
  set !recovery_delay %5
...In this snip from his recall sub, the %1 - %5 throws me off I guess.  But now I am thinking that those variables he sets are just ways to call the sub a different way easier by just changing the actual gosub line.  For instance...

Code: [Select]

gosub TM_NewCastSpell 31 !rbook 10 20 20 

He could've added %6 as a variable.

then,

Code: [Select]

; %6 = eat apple after recall

set !eatapple %6
the new sub would be called like this:

Code: [Select]

gosub TM_NewCastSpell 31 !rbook 10 20 20 #TRUE
if somewhere in the sub he programmed the %6

Code: [Select]

if %6 = #TRUE
finditem apple in pack
eat it
etc, etc

[Neo]

Okay...  So I guess it's just a way to organize variables. Now...  Might we use a sub of TM's then as example?

Code: [Select]

; %1 = spell number
; %2 = #TARGETID or SELF or NONE
; %3 = retry count (-1 = cast until successful)
; %4 = cast delay
; %5 = recovery delay
sub TM_NewCastSpell
  namespace push
  namespace local NCS
  set !lpc #LPC
  set #LPC 100
  set !whichspell %1
  set !whichtarget %2
  set !castretrymax %3
  set !waitdelay %4
  set !recovery_delay %5
...In this snip from his recall sub, the %1 - %5 throws me off I guess.  But now I am thinking that those variables he sets are just ways to call the sub a different way easier by just changing the actual gosub line.  For instance...

Code: [Select]

gosub TM_NewCastSpell 31 !rbook 10 20 20 
Yes, exactly! And %0 will be the number of those vars that are used to call the code...

He could've added %6 as a variable.

then,

Code: [Select]

; %6 = eat apple after recall

set !eatapple %6
the new sub would be called like this:

Code: [Select]

gosub TM_NewCastSpell 31 !rbook 10 20 20 #TRUE
if somewhere in the sub he programmed the %6

Code: [Select]

if %6 = #TRUE
finditem apple in pack
eat it
etc, etc

[seeriusly]

Yes, exactly! And %0 will be the number of those vars that are used to call the code...

 %0   well just when I thought I had it, you throw in a %0 that isn't even visible there?

so going by the previous example...  If there was %6 introduced to the sub... to eat an apple after recall.

you could write it like this:

gosub TM_NewCastSpell 5 31 !rbook 10 20 20

and stick a 5 in front of the 31 and it would not even worry about the %6 variable that was set?

[UOMaddog]

here's how gosub looks:

Code: [Select]

gosub NameOfSub %1 %2 %3 etc...
What %0 is, is a count of how many parameters (%1, %2, %3, etc) were passed in when the gosub was called.


So let's say you have a sub called Heal that takes a target (someone to heal) as a parameter. Before you attempt to heal something, you want to check if they actually passed you a target! Perhaps for debugging purposes. So you might have something like:

Code: [Select]

sub Heal
if %0 = 0
{
   display Hey moron! Give me someone to heal!
   return
}
else
{
   set #lobjectid %bandage
   event macro 17 0
   target 2s
   set #ltargetid %1
   event macro (whatever last target is, I sadly forget)
   return
}
return

[Endless Night]

namesspaces are just a way to make sure your variable names are unique and not going to conflict with someone elses.  This becomes an issue when you use others canned code.. and its right and proper that they should protect your code by making sure of no conflicts.

So also can emulate the usage of names space by using long var names... which i do more often than namespaces.
Ie ENs_Subs_Spells_Recall  or %BuffBarIconNamesFound %buffBarIconNames

Using a Namespace has a bunch of advantages over using long var names
You can copy a namespace and all the vars it contains, and you can delete a namespace and all the vars it contains in one go.

If you look at my buffbar scanner you will see it uses a mix of % vars and ! namespace Vars.  I use the namespace vars to make it simple for the buffbar scanner to support multiple clients at once... i do this by setting my namespace to  ENs_Buffbar . #charid  so i have a unique namespace for each char based on its id.  All the %vars have unique names %ENBB_?? internals  or %Buffbar?? for public consumption