We want the program to use the data on the most efficient level that it can. That means we should take full advantage of the datašs capabilities. If we want the data sorted and the data can sort itself, then we want the data to do that. This is going to require some sort of communication. In order to figure out what that communication process might look like I am going to look towards the only model that I know, communication between humans. To make this fit my model, Išll specifically look at communication between total strangers.
Of course, total strangers do have some things in common. If anything useful is to come of their meeting, the people have to speak the same language.
Sometimes you know who a person is and then can interact with them however you are supposed to.
Similarly sometimes an object knows the class of another object, and then can call all of its method however it likes.
Sometimes you are just getting to meet someone and you ask them a series of questions and they ask you questions and you discover compatibility and develop convenient ways to communicate.
That would be the boot-strapping process. The Objects would need to start by knowing the same language. Then they need to know a question they can ask each other. Like give me you boot-strapping process, or something like that.
I see 4 possible bootstrapping processes.
1. The program could interact with the data it is being handed and learn about it by asking questions.
This runs into an immediate problem. The data doesn't care what its context is, but the program it is being handed to could care. The only solutions are to have some sort of interaction between the two programs or to have the data contain within it its context. The advantage of using the data to do the negotiations is the data generator really just cares about generating data, not what is done with the data.
2. The program could interact with the program handing it the data and learn about the data by some procedure.
The problem here is that the generator could generate all sorts of data each of which with a different bootstrapping process. In this case it would be much more organized to allow every piece of data to have its own routine. Otherwise the bootstrapping will be ridiculously complicated. Some combination of this and the first method will probably be necessary.
3. There could be a translator
The disadvantage of this is the translator would need to know what "languages" are spoken at least in a general sense. The advantage is that data can be data and the programs that use data can do just that and only a designated translator needs to worry about communication.
4. There could be some generic form that the data can be turned into that the new program knows how to turn into something usable.
This method is by far the least universal method. Although it makes bootstrapping very easy (It is just 2 simple translations between known "languages"), only languages that are expressible in the generic form can be bootstrapped. For example XML is a generic form for any data that doesn't do anything. ASCII is a generic form for text. If you are trying to translate a document written in 13pt Times New Roman into ASCII, however, there is no way to do it without losing information. When we talk about intelligent data, finding a generic form that can express everything is infinitely more difficult.
I have decided to do some sort of a combination of the ideas above. My idea is to follow more closely the model of two humans getting to know each other. Jack might say to Jill, "What do you like to do with your free time." Jill would then formulate a response. Jill might never have been asked that before, and might never have anticipated that question, but that wouldnšt stop her from figuring out what Jack wanted to know and coming up with a suitable answer. That is because Jack DESCRIBED what he wanted using some common language. This is the mode of communication that I think might make a good model for bootstrapping.
Like in process idea 4, I will have some common form; however, it is not the data that will be translated to and from this common form, it is the bootstrapping process itself. The common from would be like a new programming language (of very limited scope). The data will get request for methods from it like in process idea one. The problem of finding the context of the data is easily solved by giving it the ability to request the context of its creator. After the receiving object requests a method from the data, the data will compile that request and use the reflection package to build a method that will perform the action the Object has requested. Then the object need mealy call the execute method and let the method do the work.
I want my methods to have the ability to take parameters at run time, not just when the method is being created. Therefor I have abstracted by NumberCommunication Class. There are now three classes with and execute method. NumberCommunication, Variable, and Constant. Constant return a value they have stored internally when there execute method is called. Variables return the first parameter in the parameter list that is passed in the execute method, and NumberCommunications have other abstract communications that they need to call the execute method of before using them as parameters for the invoke method of the method object included.
Parameter lists are represented as iterators. That way there is only one way to access the elements and the accessing can be done in only one order. At the same time Iterators are totally basic and common so this is a good abstract representation of a parameter list.
My initial methods were all static methods, so there was no problem finding a source to give to the invoke method of the Method Object. I just used NULL. But there I came upon some methods that were not static, like getValue() for example. In this case my initial quick fix was to simply write a static method like
public static Value getValue(ThingWithValue valueSource)
{
return valueSource.getValue();
}
That is not a good solution at all. In the Method object a source Object is always passed into the invoke method. This is the logical model that I should follow. My execute should not only take parameters, it should also take a source object.
That solution created a new problem. Since I am passing this source down my tree when I try and run the execute method, my methods will try and always use it as a source. There are times when I want to use no source, as in a static method, and there are times when I want to use some different source. The times when I would want to use a different source can be summed up in one area. It is when I am applying a prepositional fraise or adjective to a verb. These are three abstractly different notions of a source and should consequently be implemented in three different classes extending a common internal node Class.