In the pines, in the pines
I must make note of this mess before it leaves my head, and leaves me lost in the pines, in the pines, where the sun don’t ever shine. I would shiver the whole night through.
In the newly defined handler object, there are methods that get called when a figure is added to the realm.
Handler.realmAdd(Realm realm, Figure figure)
Handler,realmAdd(Realm realm, Figure figure, int address)
The first one only gets called by objects that implement the birth interface. The latter gets called whenever a figure gets added to the realm.
There, and it took an embarrassingly long time for me to realize it. I’d implemented Handler.realmAdd(Realm realm, Figure figure) to keep track of the largest value given to the name field in a figure. I’m reimplementing the same tests and info that were there before. When I tested it, I found that the longest value was only getting up to 1. That had me worried. I couldn’t see why it wasn’t working, especially when if I increased the argument list to implement Handler,realmAdd(Realm realm, Figure figure, int address), it worked just fine and dandy. It was around ten in the evening, while in bed, that I suddenly realized what was going on. It was a bug, in that it caused the system to act in a way I didn’t expect or want. Now, it’s a feature, as it will allow modifications to the system specific to figures added by birth objects. That’s a little more flexibility, and we’re all about that here at camp.
Meanwhile, I need to deal with methods that return values, like ints, or objects like figures. At the same time, I need to return a flag that indicates whether the default method call should take place after whatever modifications have happened. For a time, I thought I’d have to define a bunch of new classes to act as return types for the relevant handler methods—the class would hold a Boolean flag to say execute the usual method or not, and whatever type the function normally returns, so that the handler method could provide the functionality it’s changing when the default actions don’t make sense or need to be suppressed. It all makes sense, I swear!
That would work, but it’s ugly!
I don’t want other developers working with my library to have to deal with oddball return types. Instead, we give the handler another method it can override.
For example, ignoring the argument lists for now, Figure.get returns an int value. First we have a method that returns Boolean to indicate whether to call Figure.get, Handler.figureGet. If that returns false, the system calls another handler method to provide the int value, and skips Figure.get, calling Handler.figureGetInt instead.
You see the naming convention? The handler methods are named with the object where the usual method is implemented, then the method name. If it needs to return something other than Boolean, it’s the object where the usual method is implemented, followed by the method name, followed by the return type. The words are all stuck together with camel notation, and the first letter of the method name is in lowercase to stick to the usual java convention for method names. It is a much more elegant answer, and will be much easier for other programmers to work with.
I’d hoped to have my proof of concept finished up yesterday by implementing the old tests and reports that used to live in four different source code files just inside one implemented handler, but the above issues had me stuck. I’ve got a pile of things to get done today, but I might be able to reach where I’d wanted to reach yesterday today. Either that, or it will have to wait a few days while I put out the next couple of episodes.