Launchers

[aiqueneldar]

Every packet should have a launcher that handles the upstart of the classes within it's own package. Example: Interactions launcher is started by Program and the starts the launcher for the specifik UI the player chooses. Example GUI The GUI launcher then starts the MainFrame and makes sure the GUI is started correctly

EDIT (2012-05-28): Since two of us wants launcher to be static method, all be named just Launcher and excist in every package that needs them. We are going for launchers said way.

Every package that should be launched in some way should use a launcher, the launcher should be a static class and have a static method named launch which takes string arguments. The launchers should only start up the other components of the pakage and then be done.

[maandree]

I think we should name all launchers, just Launcher, and let them have public static void launch(final String... args).

This uniformity will provide better extensibility, as you will only need to know the name of the package to launch, which in case of .jar:s should be the jar's name without the .jar at the end.

[aiqueneldar]

I agree, that does make sense. I also suggest that we make an interface of Launcher with the only launch method to make sure of this uniformity

[maandree]

Interfaces requires instances, but you cannot specifies a head for a constructor, as you can with non-static methods.

Using interface will require good faith in that a parameter free constructor exists, and will require more code. Not using an interface will only require good faith in that the method exists.

Therefore I think we should not use interface for this particular mechanism.

[aiqueneldar]

Could you rephrase first paragraph? I don't understand the meaning at all.

[maandree]

If we use an interface we cannot be sure that a constructor exists that is public and takes no parameter, just as we cannot be sure that the method exists if we do not use an interface.

[aiqueneldar]

Ok, now I understand. I was thinking that you make an instance of the Launcher in question. During construction you set all the parameters needed (if any) for the Launcher and then when a new Launcher (for which ever package you are currently launching) is constructed you call the launch() method of that launcher.

I think I was unclear on that I was thinking objects not static classes. I am opting for Object because I was thinking it makes more sense when they own other objects that get started by them (the launchers that is)

[maandree]

Using parameters in the constructor, rather than in the method, will make it worse since assuming that there is a default (nullary) constructor is less exotic than assuming that there is a constructor that takes, for example, string[].

Using a static method would reduce the amount of code, but I also think objects should only be used when needed and when the data is more naturally thought of as an object. Launchers are very similar to the main class, then are not passed along between classes, they do not store data, you just run it once to start the package.

If we use interface I think the interface should have public void launch(final String[] args); # String[] is actually better than String... which I used first. and that we assume they have a default constructor.

Nevertheless I think args should alway be used, the main method should use its args as the argument for all launchers, and all launchers should pass along that args to all launchers they start.

[aiqueneldar]

We can have them static if you think that will make less code. I thought of them more naturally as objects since for example our whole networkstack only get one instance per class, and we made them into objects instead of having them static.

Secondly, the design you showed me on the whiteboard would have the network package launcher store the instances made from the networkstack. Or at least that is what I made from your design. Which would have at least the networking launcher storing data in form of the other network components. Or is that you by "data" mean other things than the other componentclasses in a package? Because if you are refereing to "data" as something else than that you are correct.

I have no problem makeing the launchers static classes. They do have large similarity with a main-method. To end a longgoing discussion I can agree with you to use static classes for launchers.

[maandree]

I'm not quite following, and am sick right now, so I'm unable to concentrate.

But in response to what I think I am able to make out of the first two paragraphs.

I never though that the launchers should store, just create. Naturally the network stack should have been static, but since every part of the program should be exchangeable, making them objects is easier, which I should have done with the engine also; I will have to fix that. When I speak of data, I normally refer to things that are sent through the network, both objects and unserialisable octets.

[maandree]

Since we agree on a design and have other issues for the launchers I'm closing this issue.

[aiqueneldar]

Then we can't close this issue without talking about what part in the package that are supposed to store the instances of the objects that get started? For example, the networking stack. What other object stores the referece to the different objects created in the networkstack? If the launcher doesn't, where does the launcher send the instances?

The diagram you drew during the meeting gave the impression that the launcher instanciate an object of every class in the package that is needed for the functionality (in network example an instance of every ?Networking class), and then keeps them in the launcher so they don't get GCed.

Where do you want to store the reference to the instances if not in Launcher?

[maandree]

I don't think and instance created by the launchers will ever need the stored. Object are only garbage collected when that are no longer used.

The frames are in use along as they are not disposed, which they never are.

BlackboardNetworking registers itself in Blackboard an is thus stored, the other *Networking are stored by the stack, GameNetworking in BlackboardNetworking, ObjectNetworking in GameNetworking and ConnectionNetworking is threaded and "stored" by itself, encapsulated classes of ConnectionNetworking stores ConnectionNetworking implicitly.

PlayerRing and Engine is registered in the Blackboard and is kept alive.

Storing in the launcher will never have an effect.

[aiqueneldar]

Ok, if you a sure that will work properly