I'm creating a text based game and inside of functions, I'm calling on other functions to go back.
Example:
I'm in the main menu.
I type shop.
It takes me to the shop function.
I do what I want and when I'm done I just call back to the main menu function.
What I'm wondering is will this type of navigation create a large stack?
If so, how can I close the current function when continuing to another?
You need to get to the end of a method call without calling a new one. Then the stack will stop growing...what you're describing could be bad.
this will cause a stack overflow quickly
public class Something
{
public static void main ( String [ ] args )
{
Something s = new Something ();
s.menu1 ();
}
public void menu1 ( )
{
menu2 ();
}
public void menu2 ( )
{
menu1 ();
}
}
I think oyou are still a little confused. Norweed's example is bad because it will cause a stack overflow. When a method completes it will automatically go back to where it was called from.
public void mainMenu() {
shop();
// program will return from shop method to here
}
public void shop() {
// add code for shop here.
// method ends and returns to mainMenu
}
if you need the program to continue then you would place a loop in mainMenu.
public void mainMenu() {
loop until user enters exit or quit or whatever {
if user entered shop {
shop();
} else if user entered library {
library();
} else if user entered school {
school();
}
}
}
> I think oyou are still a little confused. Norweed's
> example is bad because it will cause a stack
> overflow. When a method completes it will
> automatically go back to where it was called from.
>
It's not a bad example, it's an example of what NOT to do. I said that.
> > I think oyou are still a little confused.
> Norweed's
> > example is bad because it will cause a stack
> > overflow. When a method completes it will
> > automatically go back to where it was called from.
> >
>
> It's not a bad example, it's an example of what NOT
> to do. I said that.
Thats what flounder meant.
> > I think oyou are still a little confused.
> Norweed's
> > example is bad because it will cause a stack
> > overflow. When a method completes it will
> > automatically go back to where it was called from.
> >
>
> It's not a bad example, it's an example of what NOT
> to do. I said that.
That was the point. The OP seemed to think it was an example of what to do. I wonder if the OP comes from an FP background, what they're describing sounds like a Java version of CPS and will most assuredly cause a stack overflow eventually. Rather than specifying the next method execution should move to you should allow your method to return, either explicitly using "return" or implicitly by allowing it to reach the end of the method. Once it returns you're back to where it was invoked from. Generally a simple menu like you describe might be in a loop of some sort. When a selection is made the proper method to handle it is invoked. Once that method finishes it returns, the execution continues and the loop is run again.
