 So scope winds up working very differently in Ida than in many other languages and I think that's something that needs to be explained exactly how scope works in Ida. It's not terribly different but it's not exactly the same as many other languages and some of the visibility keywords work very very differently than what you'd be used to. So firstly this is essentially the, well don't go like this, this whole thing from line 4 to line 8 is the procedure block but as part of that you have the execution block and the declare block. Anything that is declared has to be inside the declare block and is visible for the entire of this procedure. Once you exit this procedure it is no longer visible. This is just a program but let's say if we had another procedure here which we wouldn't normally be able to do. Something from here would not be able to see something from here and similarly something from here would not be able to see something from here because they're inside different blocks. Essentially the entirety of Ida works that way where it's those little blocks that make it rather easy to identify exactly when something exists and where it no longer exists or is no longer visible. So we can do something like this. Foo is now one and anywhere in example Foo exists. When example is ended in this case, this specific case the program would be done and over with and the memory be freed up but if this were in just one of many procedures and start of a larger program Foo would cease to exist after this procedure is finished. It would then be recreated if this procedure was called again but it doesn't continue to exist afterwards and it doesn't exist. It's not visible to anything outside of this procedure. If you need to get even more constrained than this it is possible by using a declare block. This works much the same way but instead of procedure or whatever else it's just declare and then you have the declare block and an execution block. The execution block must exist regardless and that should make sense because it doesn't really make sense to just declare a variable and not do anything with it. Similarly to what I described before, bar does not need to exist anymore after end is called so it may be completely removed from memory but regardless anything outside of this block cannot see bar. Bar can still see things above this block so anything inside of here would still be able to see this so we can assign that to Foo. Now this would be a copy so we can manipulate it in various ways and never actually alter the original. Let's do some trying to show off some things if we do. Actually no let's just leave that. Oh yeah yeah I know. We're going to create another package so we'll just call this FooBar. Now normally inside of a package everything is public as you would normally think of it. I say normally. If you're coming from the C style world, everything in here would be public. You don't need to add a public keyword, they just are. So if we have Foo as an integer equal to one and bar as an integer equal to two, we can then include this. I need that. I do need an null here. And it builds fine. Now that's not particularly useful so let's actually do something with it. We're gonna have Foo plus bar and that's three. That's because everything in here is publicly visible. That's not always what you want though. Sometimes you want to hide things and that's why other languages have all these different keywords. Ida operates more on the idea of blocks. So what you actually wind up doing to hide any of this is a private block. Now this is very important to discuss. Private does not mean what it means in something like C++ or C sharp or Java. Private in Ida can be thought of more as it's not visible to anything that we uses that package, but it is still visible to any child packages. This is pretty similar to C sharps internal. I'm not sure what to call it in something like C++ because I know the scope keywords don't exactly line up. But just to reiterate, anything in there would be visible to child packages just not publicly. So we can go move bar over here and you can see that it's not visible. Now I can still recognize that it is declared in foobar and also in here just because the bar I think it's that symbol but yeah obviously we don't mean that one. So this can be pretty useful in that if you don't want to freely modify bar but you still want to get it you can do something like this. Oh yeah now we got to change this slightly and that still works out because this is visible just this isn't. So we can do something like, oh not that one, we can do something like this where we set foo equal to 10 instead. Because remember it's publicly visible so we can set that to something else. But if we try to set bar to something like 20, again it's not visible and even though this should seem absurd to most people, this was just a function, just a simple getter that's why I used the name. People coming from Java should recognize that. It's not a variable so you can't actually set it. So that can be used when you want something like a single 10. I had to call these abstract state machines but it's essentially a single 10 where this is the accessor and this is the actual property that you're hiding. This will have to be a procedure but we do set bar and we have value, integer and just to ensure there's no syntax errors and there's not. So then we can do set bar 20 and this winds up working out because now we have a setter instead of just assigning the variable. Now unfortunately Ida doesn't have anything like C sharps properties which are but this should seem pretty familiar to anybody who just worked with the accessor mutator patterns or getter and setter patterns in Java but we can go one step further with the hiding and that should seem pretty strange to your C developers because there's nothing more private than private but again private and Ida is more similar to internal. This isn't completely hidden. You can still see this from a child package. Suppose I'm getting slightly ahead of myself. Let's show that you can still see and operate on bar from a child package. If we do full bar and then we do bacon. Did that change on me? Oh I'm mixing up my languages again. Okay okay yep I'm mixing up my languages again. The visibility thing is a little bit more complicated than that. If we had a record defined down here you know like and then we have the abstract data type for that. The ADT is publicly visible but they can't see any of the the properties of it. A child package would be able to see the properties of it but apparently I I've never even tried to do that but apparently they can't they can't see this but it would be able to see that the the cake property existed of any type of example. So that's good to know actually. See sometimes I learn things when I do these videos because I'll make some assumptions that don't always check out like that. Be surprised how long you can actually develop in a language and not do every little thing that there is. It's not the one I want. Yeah I guess we don't need that anymore then. There's one more place we can actually put a value or anything really. One more place we can put things that makes them more hidden than private is. Remember I was getting that before. And this is gonna seem rather odd but again most languages don't actually do things the way ADTA does. You can actually define these things in the package body. Yep that entirely works out. When you'd want to do this is when you want it completely hidden. When you do not want it to be available to child packages in the apparently not always possible but the majority of the time things will actually be visible to a child package if they're declared in private. If they're declared in the body they will never be. This also has some rather important semantics in terms of building the entire systems and what needs to be rebuilt. Changes to just the body even if it's functions or values within the body of a package do not require everything that depends on it to be rebuilt. But changes to the spec even if it's the private part of the spec will require things dependent on it to be rebuilt. So essentially anything in the body itself is what would be considered private and something like C plus or C plus plus or C sharp in that it is absolutely hidden even from things even from child packages or anything else. Nothing can see this except this package. This is also useful when dealing with object orientation in that anything defined in any like functions or procedures in the body that operate on a on a tagged type, a class. Anything that inherits from it will not directly be able to use those. Though you could still use those function and procedures on them it would just be a bit of polymorphism with the downcast. While I'm doing this one other thing I will mention even though it's not explicitly like a scope or visibility thing it's not super obvious in any way that I would let this happen but essentially because a body you might have picked up that there's a little bit of this when I said that the package was essentially a singleton. Well singletons have constructors because singletons are still objects. The constructor for this where you do initialization code and I've I've never actually had to use this in practice I've just I will never forget this because it's so bizarre it just begin and then you can do things. Currently oh yeah cuz who's already yeah there you can initialization code goes there. Otherwise visibility thing not even for protected types and task types that essentially works the same. Basically visibility in Ida works three fold. It's either publicly visible privately visible or tucked away in the body where nothing other than it can see it. Scope should be pretty easily determined based on based on the block it's located in. So again if we use this as an example bar is visible to everything inside of this block but the value here is only defined in this block so we could not call value from here. I find it considerably easier to determine scope in Ida than from something like JavaScript where scope is rather confusing and you need old tutorials to figure it out. That's the tricky. Yeah all in all I say ad is pretty straightforward in this it just does a little bit differently than some other languages where you're be familiar with that do it overwhelmingly through keywords. Ida loves the block even has a syntax that's called like comb syntax because it kind of looks like a comb. That's the claim I've never actually like I get it but it's a bit of a stretch. Hope this video has been helpful. If you like what I do you like these videos please consider giving it a thumbs up and also consider subscribing. Hit the little maybe hit the little notification bell to get spammed by YouTube. Probably don't do that I wouldn't but I bring it up anyways. Yeah also considers contributing to Patreon. I don't have any big corporate sponsors or anything like that I don't have any sponsor period. Any of the code I develop any of the tutorial or educational videos that I do are purely out of my own time there's no profit for these so that would be your way of thanking me basically. I have a good one.