DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.
I just cannot think of how I should proceed for AnnotatedEnumThunk. I have the idea to use a protected class to be used with the sub-search mechanism.
I would use that rather than a method which takes tens of arguments.
Actually, what I can do is rather than storing the enumeration class and anything it contains, is to instead cache it at the start then I can run through it whenever some request is made with all of them.
My ArgumentParsing is far too complex, it currently is about just under 700 lines.
I broke my code stripping the class, that way it can be rewritten better. I solved a problem that has been on my mind coding all of this, extending off an enumeration and a handler. What I can do is pass an enumeration and some class that handles the specific data (at least for the argument parser). This way I do not have to have super complex enumerations extending off some handler and the Enum class.
I will have to figure out something because this is turning into a generic mess with type parameters thrown everywhere. A AnnotatedEnumThunk is wrong because that is for enumerations, I need some kind of super generic annotation handling thing that can run through anything that is annotated.
A class which iterates through annotations at runtime would be handy, especially if it were an Iterator of sorts or an Iterable.
A class which can take in AnnotatedElement (an array) and can iterate through it multiple times if needed, that could be done with an ArrayIterable which is similar to ArrayIterator except it creates Iterators instead.
Now with that I can use the iterable to assist in the annotation handler class. Then the annotation processor thing could also be used in my compiler and not just handling a bunch of command line options.
For fun I decided on appending a ZIP file of a source checkout to the actual repository when other/mkfossil.sh is executed. Bloats the space a bit, but it could be handy in extracting and building a source database while having the original repository on hand.
Luckily for me, my fancy upgraded fossil is backwards compatible with my more out of date fossil installations on my other systems. So I do not have to worry about that much at all. The appended ZIP file could also make a static repository on say a CD-ROM distribution a bit more sane so to speak.
But, enough distractions sort of, I wonder what the best way it would be to use something that iterates over AnnotatedElement. Perhaps a class which is constructed by an Iterable of them, of which that class itself (not the one passed to the constructor) is Iterable with a handler of sorts for each entry. Then with that, a "new" syntax for loop could be used "for (foo x : bar)". The handler will be called on every invocation (if wanted to handle). This way it is rather generic and can be done on anything. Then I can squash AnnotatedEnumThunk and replace it with that, in which ArgumentParsing uses that class instead of this giant mess I have now.
Perhaps an Iterable of Iterables that handle Annotations, although it could be very handy for a very singular annotation processor which is just an iterable of some handler type. Then stack a grouped version of that on top or perhaps a very generic class which can work on any set of iterable and run a callback of sorts. So an Iterable which takes an AnnotatedElement and emits Iterators for annotations. Then another class that does stuff on top of that. That could work. Now I need to figure out what to call it, and that could take a few hours. Something short. Perhaps something to the point, such as IterableAnnotatedElement, but that is a bit long at 25 characters. Suppose 25 is not that bad.
Not sure if I mentioned this, but in either case I can add a new part that exists above the AnnotatedElement that Iterates through those, but that would be rather complex and would be a specialized class when it can be done in a singular way. So perhaps a Factory class (despite being supposedly bad) which creates inner iterables for iteration handling and such.
My blog is quite long now, around about 2600 lines of LaTeX. I am currently tired so I am not sure if I will be capable of writing the factory or other classes. Suppose I will watch Star Trek Voyager and fall asleep somehow.
Awake now, sort of. I will have to resume work.