Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

agent (5836)

agent
  agentzh@yahoo.cn
http://agentzh.spaces.live.com/

Agent Zhang (章亦春) is a happy Yahoo! China guy who loves Perl more than anything else.

Journal of agent (5836)

Tuesday April 19, 2005
02:47 AM

Parrot Learning and CirSys Class Library refactor

[ #24269 ]

=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!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.