Comments are in. Hope you find them helpful in pointing me in the right direction. I tested the 2 argument bless in the first subroutine. When it was data dumped, I didn't see any change in how the data was stored.

It makes no difference now, nor would it matter with the way you use the returned values. But it will cause you problems later once you start having a proper class hierarchy because it breaks inheritance. Just forget the single-argument blessexists, it's no good.

I got the same result without $class on the last line. When I use the subroutine as an object, I would do something like...

my $accounts = Twitter::Objects->accounts;
for my $account (@{$accounts}) { ... }
[download]

That's not using it as an object, that's a plain old arrayref that works the same whether or not you bless it.

As 7stud and others have pointed out, the basic problem is that you haven't organized your code in an OO way so "objectifying" it doesn't work like that. You first have to identify what the "things" are in the system you're building, and what properties they have. "Accounts" would probably be such a thing---a collection of account objects. You'd pass its constructor, "new() usually, a directory that it reads to determine what the accounts are called. If stuff lives in Twitter/$account/... you can generalize that and don't have to hardcode the list. Remember the whole OO dance is supposed to help with code reuse and if the code contains your account list it's not reusable at all. So the instance data would be e.g. a directory and a list of names. Then you could ask the Accounts collection for a list of account names and for an object representing a named account. The Account class wouldn't have to know that its configuration lives in a certain directory hierarchy, it just gets passed a directory by the Accounts collection and reads its files from there. "Lists" would probably be a class of its own that somehow deals with an Accounts object, though I don't understand well enough what a "list" is in this context.

Playing with the code from perlboot should give you a better understanding of how to change your code organization so it actually benefits from OOP.