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?
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.
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.