=from 2005.4.19.11:50.AM
=to ...4.19.12:05.PM
I've been reading the POD documents shipped with the Parrot distribution. It seems to me that the Parrot assembly language is quite simple. I regard it as something similar to 8086 assembly language but with powerful string handling capabilities and a funny register type named PMC (Parrot Magic Cookie). I think I'd offer my own implementation of Parrot assembler using perl for an exercise and I may write some toy compilers that target Parrot too.
I'm considering the issue of applying Parrot to my studies in university. Is it related to Computer Organization? Um, no obvious relationship, I'm afraid. Sigh.
I will add the last 8 integration tests (say, real-world problems from textbooks) to my CirSys tester. Thus we will have in total 60 integration tests this evening. That's great!
Now that I have a rather stable dc subsystem of CirSys, I don't feel like going any further with the dc stuff now. So I'm embarking on the design and implementation of the ac subsystem.
For the sake of apparent parallelity between dc and ac libraries, I think it's a bad idea to maintain two similar versions of Elem.pm and Wire.pm respectively. I'd come up with an alternative solution. I would only maintain one version of Elem.pm and one copy of Wire.pm for both dc and ac systems, but use a global variable, for instance, $Subsystem, to denote the current system (ac or dc) that is in effect. This sounds more feasible, but I soon realized that in essence I'm using branch statements (like "if" or "switch") to check the specialized "types" of object on the fly, which is considered to be a bad design from the viewpoint of OOP, or more precisely, from the view of polymorphism. A better design is using the inheritance feature of OO. Specifically, we can refactor the class hierarchy as following:
Steady::Wire
|
|--- ac::Wire
|--- dc::Wire
Steady::Elem
|
|--- ac::Resistor
|--- ac::Inductor
|--- ac::Capacitor
|--- ...
|--- dc::Resistor
|--- ...
The introduction of Steady::* class level can make the ac and dc subsystems share most of their common code, decreasing the cost of maintenance sharply, which is exactly what we are expecting. Cool!
Okay, when I register all the integration tests I prepared, I'll release CirSys 0.07 and rapidly move to version 0.08 so as to refactor the module structure and offer a working implementation of ac subsystem. Aha!
