Sadly, no… Back to the drawing board on the API.

After making that post about my plans for the API, I sat down to do it, and instantly noted a few catches.

First of all, event handling got more complicated. I realized that each version of the API would have it’s own version of the events. This was solvable, however, so I continued.

I noted that constants got more interesting. I wouldn’t be able to have public static final variables in the API, as I’d have to set them from inside Mystcraft. This meant they couldn’t be static and final, which means that another mod could accidentally change them, which is undesirable, as that would break other add-ons.
Again, this is solvable, I’d just need to provide the constants in instanced containers. No problem.

Symbols and functions were actually going to be the easiest things to handle, and were part of why I was doing this. Each API would have an internal handler which mapped all the API calls to a core handler system (my internals, which I use). I could wrap each symbol so that the communication became uniform within my system.

Lastly I noticed that I have class definitions in the API which are used for direct communication between any add-ons. This became the stopping point. I realized that, in order to handle these objects, I’d have to have converters set up so that I convert into and out of my internal implementations and I’d have to break how communication currently works for modifiers. There would be some things which I couldn’t convert, either.

Ultimately, it looks like I won’t be able to do this, unfortunately. While looking at it, I did like some of the properties the architecture would provide, so I’ll likely try to do them regardless. I’ll also add in a check for the version of the API loaded, to ensure that Mystcraft provided the classes, and that no other mod contains the API.

I’m still going to take this opportunity to rewrite the API, and I’ll still leave out sections of it for the reasons mentioned in my previous post, but I won’t be splitting the API into packages this way.

I’ll probably continue to think about how I could version the API to make things easier for add-on developers, but this particular approach seems too limited. I can version some things, but not all of it, and if I can’t do all of it there’s not much point to doing some of it.

We’ll see how it goes. For now, I’ll continue restructuring the API.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.