[sf-perl] Advice on how to expose a class-wide preference
woof at danlo.com
Tue Mar 18 06:23:23 PDT 2008
It appears to me that you are talking about a User Interface
description. I don't know of any reason for a class API to return different
results depending on a normalized, full, or compact method. (At least I can't
think of one right now. :) Your code should never very in its return values
other wise you will be writing different APIs for each object/function to handle
receiving $data->normalized() $data->full() $data->compact() and $data->human()
$data->and_so_on. Things get exponentially worse after that.
If you are debating on how to return content for the end user, you
should always return $data->full(). Then the templating code or the display
code should be responsible for taking $data->full() and making it normalized,
compact or full.
You should consider a visitor pattern or using Template::Toolkit (very
good btw). http://en.wikipedia.org/wiki/Visitor_pattern.
This is great for deciding how you want to display the data.
You may want to check out Class::Prototyped ( very cool :)
Monday, March 17, 2008, 11:28:54 PM, you wrote:
> I'm looking for advice on how to expose a user-settable preference
> that affects the behavior of all objects in a given class. I'm working
> on a module representing data stringifiable in multiple ways, e.g.:
> I'd like to set up string operator overloading, but it's not obvious
> what the default stringification style should be; different users will
> have different needs. I'd like to allow users to choose how objects
> will stringify by default in their code. I can imagine doing this in
> two different ways:
> 1) Have a class-wide preference indicating the default style:
> 2) Let users set their preference via a magic variable:
> local $Class::default_string_style = 'normalized';
> The first option seems cleaner, and easier to subclass (were that an
> issue); it also allows for better error handling when the user calls
> the class method. Unfortunately, setting a class-wide flag also blows
> away any prior settings. Two pieces of code using the module will
> necessarily overwrite each other's preferences.
> Using a variable seems uglier, but allows users to safely intermix
> different preference values in different contexts.
> Any suggestions on which of these is generally better to use? Are
> there other strategies I'm ignoring? Thanks for any advice.
Daniel mailto:woof at danlo.com
More information about the SanFrancisco-pm