Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

OO, from a blank file: an old perler dog tries new tricks

by Intrepid (Deacon)
on Feb 21, 2013 at 03:31 UTC ( #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-driven

I 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 data

A 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).

  • Cygwin Configuration Diagnostics
  • Path: D:\UserSW\root\bin
  • Output from D:\UserSW\root\bin\id.exe
  • Here's some environment variables that may affect cygwin:
  • Here's the rest of your environment variables:
  • Scanning registry for keys with 'Cygwin' in them...
  • Cygwin installations found in the registry:
  • Listing available drives...
  • Mount entries: these map POSIX directories to your NT drives.
  • Looking to see where common programs can be found, if at all...
  • Looking for various Cygwin DLLs... (-v gives version info)
  • Checking for any Cygwin services...
  • Cygwin Package Information

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 Spec

What will be "success":

  • The “section events” will all be detected;
  • All data within each section can be manipulated (filtered, reformatted);
  • Any section can be removed from the output;
  • No “unhandled” text data will be lost after the input stream is terminated.

Design:

  • Each section will be represented in code as an object with attributes (properties, methods).
  • There will be at least 2 "dump" or "stringification" methods common to all instance/objects: plain text and YAML.
  • There will be a "filter" method for each instance/object that will receive a coderef as @_[1].
  • Each instance/object will know where in the input stream its instantiating triggering event occured.
  • There will be a common / consistent “placeholder” string representation for elided data.

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

Comment on OO, from a blank file: an old perler dog tries new tricks
Download Code

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1019876]
Approved by Paladin
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2015-07-05 15:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (67 votes), past polls