There's more than one way to do things | |
PerlMonks |
OO, from a blank file: an old perler dog tries new tricksby Intrepid (Deacon) |
on Feb 21, 2013 at 03:31 UTC ( [id://1019876]=perlmeditation: print w/replies, xml ) | Need Help?? |
I am going to try something new here. I need to write an app in Perl to parse the output of Cygwin's CygCheck.exe utility. I say "parse" as a shorthand for "read, munge, output" ;-) What is new is that I am going to try writing the spec for the app as a Meditation on PMo first before I start the app. Well, I know me, so I am already lying. I'll start to write the spec here, and then start the coding. Then return to this writeup. "Huh? Why?" Just to do something fresh, to break some habits. I am not looking for upvotes or for a way to promote my app (although I do intend to publish it; there will be a link in the post sooner or later). The habits I want to break involve the organic way my coding usually proceeds. I start out with an idea, code the skeleton, look for what breaks, decide to add some features, code, repeat, lather, rinse, repeat. It's fine, its what I enjoy. It's also not as disciplined as other approaches, leads to featuritis, and so on. (As per the top heading), I think the best way is to start with a Perl-OO approach from the beginning. That is really the realization that prompted this idea to write a Meditation. The realization is that these days, I really have no idea where to start with writing Perl-OO code. There are so many Perl-OO memes out there. There are so many helper modules on CPAN that template-ize or automate the creation of objects. Damian's book is considered a good primer, but out of date. <hands pulling out hair>. So where to begin? I'm not going to wait for advice before I make some decisions and plunge in. For a PMo newbie that would be fine, perhaps, although I do think that a lot of our newer posters don't show that they get that they need to post code from the top of their Question ...but that's neither here nor overthere. Event-drivenI know that I want to treat my input as a sequence of events. Roughly, the input data is a series of sections that describe system configuration and status data for the Cygwin installation. I will run the CygCheck.exe tool with the flags -v -s -h -r to get verbosity, helpful hints, and Registry queries. The shape of the input dataA first glance at the input we expect breaks down like this (note: to an extent this is misleading and contrived, because the CygCheck utility outputs some data that is not for public publishing).
Sweet, Eh?!This gives a Perler a true-life opportunity to test themselves against some perversely difficult input. These "headings" are highly irregular (arbitrary) in format; it may be that Localization will affect this output (I have no idea), etc. Preliminary SpecWhat will be "success":
Design:
And there we have it. Time to start coding ;-)
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the
world to himself. Therefore all progress depends on the unreasonable man." — George Bernard Shaw
Back to
Meditations
|
|