m wrote:I've finished a DV model using Java.But I didn't make use of the reflection or RTTI.What's more,it's a little DIFFERENT from what I expected.Besides I haven't tested it completely(there seems to be somethig wrong).
I'd only use reflection explicitly when there's no other option or where the other options would severely limit your design. I've used it once, so it's not a complete forbiddance, it's just a strong disrecommendation.
-This is only a model for DV.So it just describe how it would be implemented in my OS but may not be effective in a Java application.If the methods announce() takes more time than a direct recalculation,that it is used in a Java application is meaningless.(In fact,in order to get the same purpose,you can call the respective ADT EVERY TIME before you get a value.)
Direct recalculation is almost always quicker. The few times it isn't is when the other side really doesn't care about the value or only asks it every X seconds or so, where you never calculate the new value.
-Again this is a model,so the expression may not look like a common expression in Java.Instead it's contained in calc().(Candy's looks more natural,in the earlier version,I think,but I haven't read the later one.)
The second version is identical with a few minor bugs removed and a generic function wrapper and functionality. The concept is still the same.
-All the DVs make up a peer structure.And if one depends on another ALL THE TIME,it should call apply() in itself for a registration.But it only wants to get the value once,just as a CONSTANT,it doesn't need to.
My components make a syntax tree for the expression given in objects and keep booleans to indicate when what needs updating. For the rest, they're value objects. When you want to assign as an expression, use the object, otherwise use the value (.value()). This is pretty much the reason why I can't have an operator T() which gives the value, these cases would be ambiguous.
-Please notice the difference between processing a DV with an expression or a DV with only a constant(they can convert to each other during runtime).
I've chosen to keep them identical for ease of code control and simplicity. All constants and such are variables. If they're a number, you just can't change them (since you can't assign to a number).
-In fact,it should work much better if multitasking/multithreading is combined.What I think is that it may be efficient to create a Thread object whose Runnable object is designed for updating every DV evry period of time and another to response the I/O.
How do you make dynamic variables cooperate with threads? I'm missing most of the things they could do using threads.
I was still going to add the "optional" thing where you assign a value, and if a dyn<bool> evaluates to true, the value is substituted with a newer value. That would also make the change info sending more logical, since you can then actually have a function not change because of some other function to which it is listening. You could also make it not listen... hmm....
There's also another architectural error in my current code that prevents a variadic template function call from working properly. The error is that the listening is done with a template interface. You need to implement the template interface exactly once for each type you want to listen to. So if you have a function that uses two arguments of the same type, that's an error. Functions between two identical parameters are pretty common though, so that's a problem. Yet, you can solve this up to a level with a bit of template magic. That magic would completely fall to bits when you make the template variadic. Making the interface either non-template or making the implementation of the interface into a separate object fixes this problem. I'm mostly thinking of the first.
Forwarding the values themselves would work but could give problems with the second item, the variadic template idea. You'd have to make the passed type a void * or such to make that work properly which would completely remove the functionality. From a point of mathematics, you'd want to be able to make the == operator somehow associative, so that the software evaluated the entire expression into some way of making it correct. I'm not sure whether that can be useful though, since it can give a number of problems (unsolvable functions, functions with more than one answer, functions with variables that don't matter at all).
I've just thought up another thing you could do with this dynamic variable idea. You could represent the nodes of an FPGA by a dynamic variable each and make the computer perform all calculations. After the aforementioned changes it'll work properly for all types of object, although true infinite loops need a fix (hack) for not thrashing the stack (thereby causing a stack overflow).