0
Answered

Custom Units vs Reflected Types for Everything?

JasonJonesLASM 3 years ago updated 3 years ago 4

This question has pondered me since I started creating custom units, and I haven't found a solid answer yet. This isn't a scripting question itself, but more on the idea if this is at least equally on par performance wise as doing it with reflection, or better.

I know before, using time and systems already in place needing to be updated as a reason for why it's not to necessary make your own literal, or getters and setters. What if you aren't making systems intended for use outside of Bolt. You are making them new and specifically for Bolt. Would it then have any benefits with performance to do them all yourself?

I really enjoy the ability to custom organize where things go, how each unit looks and behaves. I like dealing with all the little details, and sometimes the reflected types are just not sexy, or are all bunched up in a long list down in codebase.

It has been a question that kinda holds me back because I'm always back and forth, but it would be great if my stuff I released, I knew no one needed to add anything in and It just felt like it belonged in Bolt in the first place. 

Bolt Version:
Unity Version:
Platform(s):
Scripting Backend:
.NET Version (API Compatibility Level):
GOOD, I'M SATISFIED
Satisfaction mark by JasonJonesLASM 3 years ago
Answered

I would recommend using reflected units whenever available, because they are guaranteed to operate from a codebase that is: 

  • Stabilized
  • Optimized
  • Often updated
  • Future-proof

What I mean about future-proof is that, for example, when Bolt 2 arrives, these units will automatically be compatible with script compilation, whereas your custom units won't. This will also make them literally as fast as possible, negating any performance concern.

If you want to customize reflected units further, you can add an icon to the MonoBehaviour that defines them, or add an icon manually in the editor default resources if their definer is not a MonoBehaviour. You can also customize the documentation by adding XML summary comments above the method, field or property.

Thanks for the thorough reply. I totally understand that. My inner detail oriented, do everything myself personality is haunting me. 

 So I guess my last question is, I've almost followed your design pattern to a T with most of the units, to keep everything as close to Bolts intentions as possible. It's something I agree with, and I learned a lot following your designs. Some things just aren't possible yet though How would they not be safe using your own API? Even if I update them as you update? I could stop doing the literals, the Getters and Setters that makes sense for sure and probably smart not to waste time, but the other things just aren't customizable compared to Bolts API. Like for instance, the super unit version of Do Once had to have three separate Units to accomplish with and, without, and with then. My new version allows one header to switch ports and do something different. Or my Declarations unit adds ports with three specific types as a List to populate more. Can't do any of that with super units. So none of these will be useful for the people using them, speed wise in 2.0? 

I already use Editor default resources a lot 😀 but I didn't know those summaries were what made them show up in the description. Kinda became oblivious to them.

Thanks for the great reply though, I'll be rethinking a bit. I'm pretty die hard about extending things here, it's brings me a lot of joy., Just don't want to be biting myself in the butt down the road, especially because I'm not just doing this for me, but don't want all I've worked on to have a negative impact on others.

+1

Sure, there are times when it makes sense to use the API to create new units, for instance like you did for new control structures. What should be avoided is recreating getters/setters/methods/constructors/literals.

In later versions, you'll have to provide more information in your custom units to tell Bolt how to compile them to code. But that's not for any time soon, and will be documented in due time, so don't worry too much about it for now!

Awesome, good clarification. I'll continue what I'm doing and work at removing some of the things I shouldn't have done in the future as I see the new directions of the API.

For clarification, I'm not remaking anything. I have code, but it's old and I don't even use references to them. 0 CS files in my project that aren't directly related to Bolt API anymore. The rest uses Bolts units for higher logic. Not a single monobehaviour in my project.