Saif

As a bystander in the evolution of Object-Oriented Programming in Perl, and someone who is really only just starting to get the hang of Perl modules and packages (still not any good at it), I get really quite overwhelmed by ideologies. There is considerable debate about the right way to program things, the right style, the right direction that Perl should go. It is Vim vs Emacs, Atari ST vs Amiga, Mods vs Punks. Really one needs a language to do what one needs it to do, simply, quickly and consistently. For an amateur, Perl has been able to do exactly that for me. I code rubbishly, but hey, who's looking?

But when you look at the clever people in the Perl community, you wonder. You wonder whether you are missing out by not being engaged in the evolutionary process. It is bewildering. I confess I understand a mere fraction of the terms, the rationale, the higher order coding discussions. I have read about Corinna, marvelled at Moose's capabilities, gazed admiringly at Leonerd's prowess, but do not dip my coding toes into the water. You see, I cant swim.

But every body is like, "the water is warm and safe", and "c'mon, Saif, there are no trolls here!".

Ok, ok, let's start in the shallow end. I once had a plan for a collection of "PerlayStation Console Games" (you see what I did there?). Arcade Games for the terminal written in Perl. I could resurrect that while learning "proper" OOP...POOP! But I still have to figure out Slots, Roles, lvalue, (*gasps for air*).

Let's have a plan. Breathe. The way one might develop Perl modules, is first write code without modules that works, sort of like a feasibility test. Then, perhaps separate parts that can go into a module. That module is reused in other projects, and in doing so is tweaked to allow the extended capability. A successful module can be used portably across projects. Then the same program is developed using classes in other OOP paradigms, say Corinna, then perhaps Moo,etc.

Pong was developed, a game with Sprites. The sprites contained position and motion data and the info required to draw the sprite, all contained in a hashRef, which could be passed to subroutines for processing. e.g my $sprite={x=>10....};. This was a deliberate precursor for later conversion into a blessed object e.g. my $sprite=Sprite->new(x=>10,...);, all in all a seemingly painless transformation. The sprite modules that were created from that were initially classic Packages, then eventually as classes using Object::Pad. If I can figure it out I will also use Moo. For the moment the code versions remain monolithic until we have tested it/extended it enough.

Then we measure. Ease of use, readability, code length, performance and other parameters, trying to OBJECTIVELY determine whether to dive in and enjoy the waters, or just stick to shore where it is safe.