Author Topic: A simple Analogy to help understand namespaces.  (Read 6017 times)

0 Members and 1 Guest are viewing this topic.

Offline Endless NightTopic starter

  • Global Moderator
  • *
  • *
  • Posts: 5467
  • Activity:
    0%
  • Reputation Power: 62
  • Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!
  • Respect: +393
  • Referrals: 1
    • View Profile
A simple Analogy to help understand namespaces.
« on: October 06, 2011, 05:50:51 AM »
0
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.




« Last Edit: October 06, 2011, 05:56:21 AM by Endless Night »
Outlaw Josey Wales - "Manwink, A Long Gone Scripty, and Endless are always teasing us with their private sections lol. What there realy saying is scripters rule and users drool."
Briza - "Your a living breathing vortex of usefulness."

Offline Neo

  • Prime Program
  • Elite
  • *
  • *
  • Posts: 821
  • Activity:
    0%
  • Reputation Power: 13
  • Neo barely matters.Neo barely matters.
  • Respect: +155
  • Referrals: 3
    • View Profile
Re: A simple Analogy to help understand namespaces.
« Reply #1 on: October 06, 2011, 08:18:00 AM »
0
Hehe, nice way of explaining this, I bet this will help out those who are struggling to understand namespaces...

Great initiative!
Never refuse an invitation.
Never resist the unfamiliar.
Never fail to be polite.
And never outstay your welcome.

Offline seeriusly

  • Full Member
  • ***
  • Posts: 219
  • Activity:
    0%
  • Reputation Power: 6
  • seeriusly has no influence.
  • Gender: Male
  • Respect: +40
  • Referrals: 0
    • View Profile
Re: A simple Analogy to help understand namespaces.
« Reply #2 on: October 06, 2011, 04:04:10 PM »
0
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...  :-\


Offline UOMaddog

  • Maddog
  • Elite
  • *
  • *
  • Posts: 1625
  • Activity:
    0%
  • Reputation Power: 22
  • UOMaddog might someday be someone...UOMaddog might someday be someone...UOMaddog might someday be someone...UOMaddog might someday be someone...
  • Gender: Male
  • Biggest B@D@$$ of the Universe
  • Respect: +165
  • Referrals: 8
    • View Profile
    • Insane UO
Re: A simple Analogy to help understand namespaces.
« Reply #3 on: October 06, 2011, 04:26:41 PM »
0
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!
There are 10 kinds of people in this world: those that understand binary and those that don't!

Windows:  A 64-bit tweak of a 32-bit extension to a 16-bit user interface for an 8-bit operating system based on a 4-bit architecture from a 2-bit company that can't stand 1 bit of competition!

Offline Neo

  • Prime Program
  • Elite
  • *
  • *
  • Posts: 821
  • Activity:
    0%
  • Reputation Power: 13
  • Neo barely matters.Neo barely matters.
  • Respect: +155
  • Referrals: 3
    • View Profile
Re: A simple Analogy to help understand namespaces.
« Reply #4 on: October 06, 2011, 05:08:20 PM »
0
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! :D
Never refuse an invitation.
Never resist the unfamiliar.
Never fail to be polite.
And never outstay your welcome.

Offline TrailMyx

  • Officially retired from UO
  • Administrator
  • *
  • *
  • Posts: 13301
  • Activity:
    0%
  • Reputation Power: 154
  • TrailMyx is awe-inspiring!TrailMyx is awe-inspiring!TrailMyx is awe-inspiring!TrailMyx is awe-inspiring!TrailMyx is awe-inspiring!TrailMyx is awe-inspiring!TrailMyx is awe-inspiring!TrailMyx is awe-inspiring!TrailMyx is awe-inspiring!TrailMyx is awe-inspiring!TrailMyx is awe-inspiring!TrailMyx is awe-inspiring!
  • Gender: Male
  • Viper!
  • Respect: +1349
  • Referrals: 33
    • View Profile
    • ScriptUO
Re: A simple Analogy to help understand namespaces.
« Reply #5 on: October 06, 2011, 05:36:09 PM »
0
Great initiative!

That's why we pay him the big bucks!
Please read the ScriptUO site RULES
Come play RIFT with me!

Offline seeriusly

  • Full Member
  • ***
  • Posts: 219
  • Activity:
    0%
  • Reputation Power: 6
  • seeriusly has no influence.
  • Gender: Male
  • Respect: +40
  • Referrals: 0
    • View Profile
Re: A simple Analogy to help understand namespaces.
« Reply #6 on: October 06, 2011, 05:40:44 PM »
0
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


Offline Neo

  • Prime Program
  • Elite
  • *
  • *
  • Posts: 821
  • Activity:
    0%
  • Reputation Power: 13
  • Neo barely matters.Neo barely matters.
  • Respect: +155
  • Referrals: 3
    • View Profile
Re: A simple Analogy to help understand namespaces.
« Reply #7 on: October 06, 2011, 06:25:16 PM »
0
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


Never refuse an invitation.
Never resist the unfamiliar.
Never fail to be polite.
And never outstay your welcome.

Offline seeriusly

  • Full Member
  • ***
  • Posts: 219
  • Activity:
    0%
  • Reputation Power: 6
  • seeriusly has no influence.
  • Gender: Male
  • Respect: +40
  • Referrals: 0
    • View Profile
Re: A simple Analogy to help understand namespaces.
« Reply #8 on: October 06, 2011, 06:41:53 PM »
0
Quote
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?

Offline UOMaddog

  • Maddog
  • Elite
  • *
  • *
  • Posts: 1625
  • Activity:
    0%
  • Reputation Power: 22
  • UOMaddog might someday be someone...UOMaddog might someday be someone...UOMaddog might someday be someone...UOMaddog might someday be someone...
  • Gender: Male
  • Biggest B@D@$$ of the Universe
  • Respect: +165
  • Referrals: 8
    • View Profile
    • Insane UO
Re: A simple Analogy to help understand namespaces.
« Reply #9 on: October 06, 2011, 07:50:26 PM »
0
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
There are 10 kinds of people in this world: those that understand binary and those that don't!

Windows:  A 64-bit tweak of a 32-bit extension to a 16-bit user interface for an 8-bit operating system based on a 4-bit architecture from a 2-bit company that can't stand 1 bit of competition!

Offline Endless NightTopic starter

  • Global Moderator
  • *
  • *
  • Posts: 5467
  • Activity:
    0%
  • Reputation Power: 62
  • Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!Endless Night is awe-inspiring!
  • Respect: +393
  • Referrals: 1
    • View Profile
Re: A simple Analogy to help understand namespaces.
« Reply #10 on: October 06, 2011, 08:48:18 PM »
0
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

Outlaw Josey Wales - "Manwink, A Long Gone Scripty, and Endless are always teasing us with their private sections lol. What there realy saying is scripters rule and users drool."
Briza - "Your a living breathing vortex of usefulness."

Tags: