This is a concern as I am considering an incremental move over to a OO style and higher levels of abstraction. How might OO design or some other abstraction help me support this dual-interface ability?

Easily

{
   package UI;
   ...
   sub refresh_track_display {}
   ...
}

{
   package UI::Graphical;
   our @ISA = 'UI';
   ...
   sub refresh_track_display {
      ...
   }
   ...
}

{
   package UI::Text;
   our @ISA = 'UI';
   ...
   # Inherit no-op refresh_track_display.
   ...
}

...
$ui->refresh_track_display();
...
[download]

This is good, because I have a few more of these conditionals, and everywhere around them feels brittle and I feel pinched by them. These are thorns I can remove from my dreams as well. :-)

I am happy that I can refine code that I already have. I think I'm no longer envious of those LISP guys, living in their clouds of parentheses.

For the first time, I feel that I understand how a hierarchy would work, and in fact, have used them already with Tk.

A UI class might be at the top, a Session might inherit from that, and specify a group of recordings and data structures expressing the routing and processing specifics(as it already does in my procedural code).

I can see how each level can add its own subroutines in a neat way. I am gleeful that I can accomplish this directly using something lightweight like Object::Tiny. Encouraged by the simplicity, excited to get at these possibilities with less boilerplate, from which I would also like to liberate my dreams and waking hours.:-)

I am happy to think I can develop more succinct ways to say and get to what I want in code.

I'm thrilled to begin getting this... although some hours are going by...

As stand-alone code, this example produces the expected output. As a module (built with the h2xs boilerplate) make test fails with:

Tried to use 'TestOO'. # Error: Can't locate object method "new" via package "UI::Graphical" at /media/jroth/ecmd-dev/TestOO/blib/lib/TestOO.pm line 56.

Any ideas about this? I just pasted this stuff into the 'precompiled methods go here' indicator in the boilerplate.

Is there a reason why the children would inherit 'new' from the superclass in one context and not in another?

package UI;
use Object::Tiny qw(dummy);
sub hello {print "superclass hello\n"};

package UI::Graphical;
@ISA = 'UI';
sub hello {print "make a window\n";}

my $ui = UI->new;
$ui->hello;
$ui = UI::Graphical->new;
$ui->hello;
1;
[download]

Are you sure that's the code you ran? It should work. And it works for me.

>perl 655812.pl
superclass hello
make a window
[download]

use Object::Tiny qw(dummy);
can be written as
use Object::Tiny;
but not as
use Object::Tiny qw( ); or
use Object::Tiny ( );
You would get the error you showed if you did one of the latter two.

Also, if you have no members, you can use
$ui = 'UI'; instead of $ui = UI->new();, and
$ui = 'UI::Graphical'; instead of $ui = UI::Graphical->new();.
However, you'll probably need some members, so you might as well continue the way you are going.

As ikegami indicated above, one and/or the other UI approach could make use of functions that are available only for that particular UI, but since these are UI differences, they would have no impact on the back-end data processing module(s).

Thanks for the hints, graff

My display and back-end functions are mostly separate as procedural code. I can see that once I get over the cusp of using the OO features (getting them to work in the module build/testing framework) my code base is going to become much more solid.