Ok, I see what you're trying to do. Initially I wasn't sure if OO made sense, because part of the reason of having a class is that it presents a well-defined API. If the methods available on an object begin varying, you lose the advantage of a clearly defined API (and with a hash, one can at least use the keys function to see what keys are present). But if the methods are defined by the column names in a spreadsheet, then presumably the user knows what those column names are, so it's not so bad.

So, you could do it with OO; I the way I would look at it is this: Your object could have a generic get_column method, like ->get_column("column_name"), and a get_columns method that lists the available column names (so far, we've just re-created a hash-like interface). Then, your object could provide dynamically created ->column_name methods as syntactic sugar for ->get_column("column_name"). So far I think this is what you are planning? Problem 1: What if the column name overlaps with an existing method? For example a column named get_column, or isa (inherited from UNIVERSAL). Problem 2: Method calls don't interpolate in strings, while hash lookups do ("$foo->bar" vs. "$foo{bar}").

So sure, you could use an object, but unless your object would provide more functionality that you haven't mentioned yet, I don't yet see the advantage.

(P.S. I see mbethke and duelafn posted similar thoughts while I was typing :-) )