Decide What to call Our dependency inversion project

[erendrake]

I added a new project to the kOS solution last night. The purpose of this project is to be a Dependency Inversion container that will hold all of the code that doesnt depend directly on The UnityEngine or KSP assemblies. I was able to pull all of the compilation namespace over and some other base classes with more to come.

In doing this i came up with a frankly crappy name kOS.Safe. Meaning it was safe from the tyranny of unityengine and it is code that can be unit tested and could maybe even be run outside the KSP environment. This name is kinda lame and i would like for it to have a better one before too long.

Ideas:

• kOS.Base
• kOS.Core
• kOS.Inverted
• kOS.Testable

Alternatively, it could be that there are, in fact, Many projects lurking inside this one and some of the namespaces that we currently have could be their own project.

Candidates Include:

• kOS.Compilation
• kOS.Execution
• kOS.Encapsulation
• kOS.Compliation.KS (likely rename to .Kerboscript)

[erendrake]

After writing this I think I might have formed some ideas.

Maybe both solutions are valid? "kOS.Base" or common or whatever we call it might be a good place for holding our most basic abstractions. Then kOS.Compliation could be its own project that stores that namespace in a way that lets us control references better.

Because the big reason for doing this is for unit tests, We also need to decide on a Testing Framework. Looks like sharpdevelop supports NUnit and it is a fine tool so i think ill go with that unless something comes up.

@Dunbaratu what do you think?

[Dunbaratu]

I don't see the need for the entire endeavor, to be honest. That's why I'm staying out of it and letting you deal with it if you want it. Adding a simple feature to a class will now mean adding code in 3 different places (kOS.Base, kOS, and the interface shared between them), and the split of what goes where will require knowing low level implementation details, sort of defeating the whole point of encapsulating things in classes and hiding details behind the facade of method calls and property names. Now the amount of information a programmer needs to be a contributor is much higher. Adding complexity to the system creates a larger barrier to getting more developers.

As for NUnit. I've never used it. I'm of the opinion that IDEs must be optional tools to help the programmer, and the moment they become mandatory tools a line has been crossed that I don't like. kOS should be compilable by someone who's just using a text editor and a command line compiler. Does NUnit mean the project will now need the IDE? If the answer is yes, then I would say, "don't use it". If the answer is "no", then I don't care.

[erendrake]

@Dunbaratu Good to know. and NUnit has a standalone test runner so no IDE is required. I also agree that IDE independence is a good thing.

[pjf]

+1 for anything that gives us more testing. +1 again if it's anything that can run via travis so we can do continuous integration, which means developers don't even need the test framework to make contributions. Stack overflow suggests that Nunit is a good choice here, if perhaps a bit fiddly to get up and running the first time.

As for namespaces, no opinion, lest I suggest kOS.Bikeshed. ;)

[Dunbaratu]

For syntax regression, which is a lot messier to test because it must read the syntax from a file to really be a proper good test of the parser, you'll have to work out how to make sure the test suite has:

a CPU object, a ScriptHandler 0bject,

Because the compiler is hardcoded to use those.

Your tester will need, basically, a stripped-down gutted version of "Shared" that creates an environment in which the vessel isn't a real vessel and so on.

Perhaps that will mean having to make an implementation of the ICpu interface and the IVesselTarget and so on that have very little innards and just dummy stubs of all the methods that can't work without KSP. (i.e. a version of VesselTarget that when asked for its GetPosition, returns a zero vector, and when asked for its GetVelocity, returns a zero vector, and when asked for its :NAME suffix, returns a dummy string, and so on.)

I can't think of a way to test syntax regression in an automated way without that sort of thing. SharedObjects is really the execution environment (and Environment would have been a better name for it, come to think of it), so it's not reasonable to ask all kOS.Safe code (or whatever it gets called) to be able to operate without one. But maybe the Test code could generate a dummy variant of Shared that does the same stuff kOSProcessor.InitObjects() does, but fills Shared with dummies that have a lot of the methods directed to do empty things.

To give an example of what I mean: To compile a one-line kerboscript program and try running it, you need to let the compiler see a current execution context, which is associated with a current cpu and a current volume, and so on.

I am not in any way volunteering to actually do this. Just mentioning what needs to be done if you want to set it up.

Once you have one or two examples set up to see how you solved it, then I might be willing to add more test cases to the tests, but I don't want to be the one to actually set up the infrastructure that supports it, as I've got my head in other areas.

I was thinking of this because the thing I am working on required re-writing about 10 lines of the TinyPG syntax file in a way that I thought, "man, this could be dangerous and needs checking." I expect some regressions to fail because we're fixing long-standing holes in the language that are bad the way they are, but I'm hoping that I get only the changes I intended to get and not changes I wasn't expecting to get.

[Dunbaratu]

We need something quickly for debug printing statements inside kOS.Safe

With what you've done so far with this it has now become impossible to call UnityEngine.Debug.Log from within kOS.Safe, making some of the development I'm trying to do a bit messy and difficult. Can we have a fast priority on getting something working for logging from within kOS.Safe, even if it's just a dumb system for now? Something that just lets kOS.Safe access KSPLogger.cs (and then maybe KSPLogger.cs dumps to a file outside of KSP when KSP isn't hooked up.)

In the meantime I'm resorting to trying Console.WriteLine and making sure I run KSP.exe from a command prompt.