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

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.
  • Hi,

    This sounds interesting, could you explain it more thoroughly... I often struggle with having made bad design decisions so I am always open to smart ideas and designs or architectures
    • It's pretty simple, really. Let's say that I have an object that sends messages to other objects. We'll call those "helper objects". What API should I use with the helper objects? If I start by trying to design them, it may not be immediately clear how they are used.

      For example, I have a variant of a status system that I've been using, but I needed to improve on the old API. My purchase orders can be "pending", "sent", "cancelled", or "received". These statuses are actually helper objects that allow the purchase order to inspect itself and override some internal behavior. (There's a reason why these weren't subclasses, but that would be a pointless digression). So how do I create "status" objects? I knew roughly how to implement them, but I couldn't nail it down exactly. However, once I started to flesh out the purchase order object, creating the status system was obvious:

      sub create {
          my ($class, $data) = @_;
          # new pos are *always* pending
          my $pending = POStatus->retrieve(POStatus->PENDING);
          $data->{status} = $pending;
          $class->SUPER::create($data);
      }

      When I was trying to create the API by starting with the status system, it simply wasn't obvious how the type system was going to be used. Once I had to use the type system, I didn't even think about it. The API was obvious.