byterock

Well carrying on from my last post lets get a little idea what the SQLDataAccessor was suppose to be doing. It was part of a larger system called DataAccessor that was attempting to provide a common CRUD front end to a number of data sources. There was SQLDataAccessor, SIPDataAccessor of course and NTFSDataAccessor and I think an OLEDataAccessor as well. At the time a rather novel idea.

On top of this access layer there was a Java bean layer (abstract classes really) then a java servlet *.do layer (remember good old Apache Jakarta) and then finally the front end and for that we had a web version in JSP a Java App for desktop and phone (very early days) and a WAP stack as well.

My part of the team I guess would be called bit player as my job at the time was to create most of the beans and thus an endless stream of init statements à la,

 


    private String someProperty = null;

followed later on by an even longer stream of setters and getter subs such as

 
    Public Sting getSomeProperty(){
       return (this.someProperty)
    } 

    Public Sting setSomeProperty(String, someProperty){

       this.someProperty =  someProperty

    }

then of course I would follow up these inspirational lines with an equally awesome set of junit tests

   public void testSomething(){

      MyClass =  new SomeClass();

     ...

anyway you get the picture. I was a very low person on the totem pole, though I must admit I was well paid for it.

Alas! some time later, when I was part of the team making LAMP SIP apps, I was assigned to recreate the abstract classes and yet again I faced that endless stream of setters and getters starting first in PHP then switching over to Perl mid way.

The only book we had handy was ok for the web side of things but I needed a little more in depth for what we where working on.

So I took a peek into the guts of DBI, most of it was Greek to me but I did notice that it had hash of classes and methods that was processed though an '_install_method' sub. Its still there by the way at about line 500.

Looking closer I saw that the code was creating code and that's when it dawned on me that maybe there is more to this Perl than just a way to make web pages.

So I though if you can use a sub to generate methods why not use a sub to generate attributes! After all, a getter and setter are just methods.

Suddenly my abstract classes started to have just a single loop at the top

 
foreach my $field ('first_name','last_name','Address') {
      my $set_method= "contact\::$field";
      my $set_code = "sub {
          my \$self = shift;
          if (\@_) {
            \$self->{$field} = shift;
            return 1;
          }
          return \$self->{$field};
        };";
     {
       no strict qw(refs);
       my $set_code_ref   = eval qq{#line 1 "$imp_class $set_method "\n$set_code};
       *$set_method        = $set_code_ref;
     }
   }

and little else.

Well after a few of these I figured well I could just put this in a package then I would not have to copy my loop in each class and my first Perl Mod was born.

About the same time the first crack at the Perl DataAccessor was taking form and our lead programmer took what I was doing an reused it in his class and that lead to me doing a much expanded version of my package so I finally was contributing more than just simple set and get abstract classes and web pages.

Let's fast forward a few years and I find myself hooked on Perl, working as a the DBD::Oracle maintainer and going to my first conference good old YAPC '09 in Vienna.

While there I heard of a funny little thing called Moose which made me giggle a bit as I sort of stumble on it myself some years before.

Well as one thing led to another I finally got my own CPAN account and my very first module was Orignal an evolved version of my very fist package. The name, of course, is a little bit of a joke as it is hard for both English and Hebrew speakers to say.

but that is another story