Scary Reflection stuff when wrapping an implicit operator.

[codepoet]

There better be 2 CLSInterface.dll's, to make sure KSP can load them properly. Yes, KSP should only load the first one it finds and reuse that, as long as they have the same assembly name, version, etc. Otherwise it would be two different types internally and thus wouldn't work.

Btw, with interfaces you definitively can't use operators

Instead you will have a single [singelton?] class / .cs file SM has to include that takes care of stuff like that and "first contact" in general (e.g. getting a reference to some singelton object that implements a general "manager" interface).

This is all starting to sound muck more familiar from my COM background - well defined, versioned interfaces, object managers, bliss!

Does KSP not have some sort of object manager for objects that inherit from KSPAddon, (which CLS does)? I would have thought that SM or whoever could just say to KSP "can I have the KSPAddonn called CLS please", as KSP must have a list of them all somewhere.

Blizzy, I would live to hear what makes you uncomfortable about using interfaces this way. From my perspective this what interfaces are for. However I have not been doing this commercially for 6 years, and can't possibly keep up, so perhaps I am hopelessly out of date. I have to say I am surprised that it is provibg so hard in C# / .Net to write a component, and then provide it in a way that lots of others can use it. Surely that is one of the first goals for any component architecture.

Thanks for a good quality chat guys it is some much more refreshing to talk to you, than to folks saying "you broke my gameplay".

[blizzy78]

Blizzy, I would live to hear what makes you uncomfortable about using interfaces this way. From my perspective this what interfaces are for.

I'm not saying that this isn't what interfaces are for, just that you seem to be overcomplicating things (at least to me.)

[codepoet]

Fair enough. In that case, what is the simpler solution?

[Papa_Joe]

This is all starting to sound muck more familiar from my COM background - well defined, versioned interfaces, object managers, bliss!

Does KSP not have some sort of object manager for objects that inherit from KSPAddon, (which CLS does)? I would have thought that SM or whoever could just say to KSP "can I have the KSPAddonn called CLS please", as KSP must have a list of them all somewhere.

Blizzy, I would live to hear what makes you uncomfortable about using interfaces this way. From my perspective this what interfaces are for. However I have not been doing this commercially for 6 years, and can't possibly keep up, so perhaps I am hopelessly out of date. I have to say I am surprised that it is provibg so hard in C# / .Net to write a component, and then provide it in a way that lots of others can use it. Surely that is one of the first goals for any component architecture.

Thanks for a good quality chat guys it is some much more refreshing to talk to you, than to folks saying "you broke my gameplay".

I'm somewhat in the same position. I've got over 20 years experience in software, but I've never had to create dynamic binding for assemblies, as the environment was "contained". If i needed an assembly, it was available for distribution with the code. So my skills in that area are definitely lacking.

I undrstand the concepts tho and can certainly code to it with a bit of assistance from google.

From my experience, the simplest solution generaly works the best, and good complexity is built upon good simple component. CLS is certainly written this way. Unfortunately, SM is not. I'm working towards that, with constant refactoring each update.. I have to be careful tho as I can break what was working in the process...

Good talk all. I'll be here to help with testing any potential solution. Even if we test and scrap, it is an education for me and that is priceless.

Edited May 13, 2014 by Papa_Joe

[codepoet]

The thing about CLS is that it has no value on its own - the whole point is that it is of use to other mods. So the mechanism by which other mods use it is one of its features, and it is important to get it right...

Anyhow, I think I can see a way forward. I suspect it is not the most ".Net" solution, but it is one that:

1) makes sense to me,

2) reduces the amount of code the I have to tell people to add to their project.

3) reduces the number of reflection calls to one.

The downside is that mods that want to loose bind to CLS will have to ship an extra file with their mod. However the promise is that that file will generally stay the same, even when CLS changes.

[codepoet]

Amazing! I use some concepts that I actually understand, rather than swanky new language features that look cool, but I do not understand, and it seems to just work first time!

Now for some proper testing. Things look good folks!

In particular, PapaJoe, it looks like pretty soon you will be able to tell folks that they can uninstall CLS and it will not cause a problem

[Faark]

I have to say I am surprised that it is provibg so hard in C# / .Net to write a component, and then provide it in a way that lots of others can use it.

I'm not sure whether you can entirely blame .NET for that. Keep in mind that we have to live the environment provided by KSP / Unity. .NET offers ways to manually "choose" what assembly to load, what could solve the two major issues we have here (different version numbers and assembly locations), but afaik there isn't any way to get this in place for KSP before the mods fail to load.

Even if we test and scrap, it is an education for me and that is priceless.

Thats kind of another argument i was about to make in favor of interfaces. Pure reflection is proven to work by blizzy/toolbar, but having an additional approach tested will definitively be interesting. Wonder what advantages or disadvantages we might not even have considered, yet. At least so far i don't see any bigger disadvantage.

[Papa_Joe]

I would like to announce that I have tested codepoet's proposed solution to soft dependencies, and it works. We had one small tweak to the client class, but other than that... looks great!

Interface based, and only a reflection call when a resource is changed or vessel changes.

I'm working out some bugs as a result of some problems with my highlighting scheme (it needed work anyway), but we should be seeing a soft dependency release of SM very soon.

Thanks to all, and to codepoet who "made it work"!

[codepoet]

Good. Thanks for all the help guys.