Passing Context to Classes

[dQw4w9WgXcQ 184]

24 minutes ago, Man16 said:

You can get the methodcontext statically through the client class, but I'm not sure how this will work. I've done it when I've been lazy af.

doesnt work with tabs, it will get the client that corresponds to the first instance

[Manly 879]

11 minutes ago, dQw4w9WgXcQ said:

doesnt work with tabs, it will get the client that corresponds to the first instance

Ah. Not a problem for me since I use 1 tab per instance anyways.

[sintaax 0]

default package works great for an entry unless for whatever backwards reason I need to reference the entry

 

also, can't seem to start scripts where the entry is not located in the default package so there's that

[Dreamlicker 750]

you could make a singleton accessor for the context like

 

public class Accessor {
	
	private Accessor instance;
	private MethodContext context;
	
	private Accessor() {}

	public static void Initialize(MethodContext context) {
		instance = new Accessor();
		instance.context = context;
	}

	public static Accessor GetInstance() {
		return instance;
	}

	public MethodContext getContext() {
		return context;
	}
}

public class mainscript extends etc {

	public void onStart() {
		Accessor.Initialize(getContextWithWhateverMethodItIs);
	}
}

public class otherdude {
	private MethodContext context;

	public otherdude() {
		context = Accessor.getInstance().getContext();		
	}

	public void eat() {
		context.GetInventory().get(i -> i.getName().equals("Tuna")).interact("Eat");
	}
}

 

[dQw4w9WgXcQ 184]

better to just pass the main script to the accessor and make it generic

[Dreamlicker 750]

15 hours ago, dQw4w9WgXcQ said:

better to just pass the main script to the accessor and make it generic

You cant make that generic. If you think you can, post code that compiles. I'll give you $5.

Why would you pass the main script? It does not make it any clearer. 

[dQw4w9WgXcQ 184]

8 hours ago, Dreamlicker said:

You cant make that generic. If you think you can, post code that compiles. I'll give you $5.

Why would you pass the main script? It does not make it any clearer. 

 

sorry wasn't thinking.  

however, shouldn't use singleton with instanced api.  

With an instanced accessor, its better to pass the main script because you can access done(),etc. and any methods you create.  theres no reason not to.  Otherwise you would need a separate context to hold w.e. methods you create.  It's really not as messy as you would think to just put your methods in a RickkScript (super to main script) and use the inheritance hierarchy rather than an instance of RickkContext.    It's not ideal, but since the default MethodContext is the main script itself, its inherently messy.  

[Dreamlicker 750]

19 hours ago, dQw4w9WgXcQ said:

 

sorry wasn't thinking.  

however, shouldn't use singleton with instanced api.  

With an instanced accessor, its better to pass the main script because you can access done(),etc. and any methods you create.  theres no reason not to.  Otherwise you would need a separate context to hold w.e. methods you create.  It's really not as messy as you would think to just put your methods in a RickkScript (super to main script) and use the inheritance hierarchy rather than an instance of RickkContext.    It's not ideal, but since the default MethodContext is the main script itself, its inherently messy.  

There is a reason not to, it's that the point of the class is to access the method context of the script from any class without having to pass around the context. That is explicitly what OP wanted as far as I can tell.

Utilizing methods within the main script from within the accessor is bad design, and not only because the purpose of the accessor is not to use the main script class.

You don't create separate method contexts. You use the accessor to operate on/with the context from within other classes that have their own responsibilities (single responsibility principle).

The fact that it's a singleton means nothing in regard to the api/script/whatever. The only point of a singleton is to provide a global access point to an object that is guaranteed to only have a single instance, preventing duplication of objects it contains. The example I posted is slightly weak as we're trying to ensure that the class receives a dependency through the initialize method, but if you ensure that you only ever call the initialize method from onStart, you can avoid that pitfall. Better yet, utilizing a class that inherits from AbstractScript or TaskScript and calling initialize in onStart within that class (and extending from it to create your main script class) will ensure you avoid any issues.

 

A well designed system does not put every piece of functionality into a single place, avoiding an anti-pattern (the blob). It's important to promote separation of concerns in your design, which the accessor facilitates.

 

However, I think it's a little silly to not just pass the context in the constructor as you're going to be instantiating it somewhere anyways. You could use a factory to handle the dependency injection if you really wanted.

 

In general, none of this is really reasonable unless you're making a large script. If OP is, then i'd design it like I would any other program. If not, sticking most everything in the script class/nodes is not that big of a deal.

[dQw4w9WgXcQ 184]

8 hours ago, Dreamlicker said:

There is a reason not to, it's that the point of the class is to access the method context of the script from any class without having to pass around the context. That is explicitly what OP wanted as far as I can tell.

Utilizing methods within the main script from within the accessor is bad design, and not only because the purpose of the accessor is not to use the main script class.

You don't create separate method contexts. You use the accessor to operate on/with the context from within other classes that have their own responsibilities (single responsibility principle).

The fact that it's a singleton means nothing in regard to the api/script/whatever. The only point of a singleton is to provide a global access point to an object that is guaranteed to only have a single instance, preventing duplication of objects it contains. The example I posted is slightly weak as we're trying to ensure that the class receives a dependency through the initialize method, but if you ensure that you only ever call the initialize method from onStart, you can avoid that pitfall. Better yet, utilizing a class that inherits from AbstractScript or TaskScript and calling initialize in onStart within that class (and extending from it to create your main script class) will ensure you avoid any issues.

 

A well designed system does not put every piece of functionality into a single place, avoiding an anti-pattern (the blob). It's important to promote separation of concerns in your design, which the accessor facilitates.

 

However, I think it's a little silly to not just pass the context in the constructor as you're going to be instantiating it somewhere anyways. You could use a factory to handle the dependency injection if you really wanted.

 

In general, none of this is really reasonable unless you're making a large script. If OP is, then i'd design it like I would any other program. If not, sticking most everything in the script class/nodes is not that big of a deal.

Using static classes in this way won't work with tabs since each tab will be trying to init/get from the same static instance.  

The agree with the rest of your points to an extent, but it's more applicable to larger scripts.  For example, if he wants a method to check wild level(the DB one is broken), he would have to create a separate context and pass that along with method context to all the nodes.  A lot of the blob concerns are a consequence of the way the DB API is laidout with the script already inheriting method context and also being the entry point for messagelistener.  for this reason i still believe its best to pass the entire main instead of methodcontext.  you have to pass it to access done(), randommanager, etc.  there is no downside to passing it.  

 

To be clear, getWildernessLevel would be in a WildernessMethods class in the main script or a super of main 

[Dreamlicker 750]

15 minutes ago, dQw4w9WgXcQ said:

Using static classes in this way won't work with tabs since each tab will be trying to init/get from the same static instance.  

 

 

ya dont use tabs