in reply to Re: Perl and Google Charts extended encoding
in thread Perl and Google Charts extended encoding

You're right about being almost a CPAN module. But for the minimal case of encoding one string format to another, there is no reason for OOP.

If you provide a way to work with data sets in the abstract, an OOP approach starts to make sense.

Note that you could just as easily expose a few functions and handle everything as native structures and go 100% procedural here, as well. OOP could be a nice win if you have a group of similar encodings that use scaling functions and serialization in similar ways. Then you'll actually be able to benefit from inheritance (at least if you designed your class to support the correct abstractions).

An even better choice would be to check CPAN and see if there are any multi-front-end charting libraries that could be extended to include this output format. What you do then will depend on the charting API's needs.

Oh, BTW, don't do bless( $self );, it silently breaks inheritance. Use 2 argument bless instead. The invoking class name is available as the first argument to your constructor. bless $self, $class;

TGI says moo

Replies are listed 'Best First'.
Re^3: Perl and Google Charts extended encoding
by davido (Cardinal) on May 04, 2011 at 16:39 UTC

    Thanks for the insight, and for the suggestion on 2-arg bless. I raised a few eyebrows by suggesting an OOP approach, and I do understand the reluctance for such a trivial situation. My thought was to avoid polluting namespaces with a function that had such a generic name. But the OP would have options: One, don't export, and do use the fully qualified name. Two, do export, but make it optional to do so. Three, offer both an OO interface and an optional export list. That's probably best. To your point, it doesn't make a lot of sense with just one function, but as functionality gets added, it starts making more sense.