And this is one of the reasons why I asked. Sometimes I latch on to a single design viewpoint, and then I have no one to knock sense into me ;-)
What I am trying to figure out is how the user will be able to override things this way. For example, if I factor out a function that "gets" the order of the parameters to be parsed, how does the user override that to reorder them? Or, more likely, some of the usage functions. With package methods, this is easy - we can re-use the built-in perl functions for doing so by simply capturing the first parameter and using it for dispatching to the next section. my $class = shift; ... $class->display_help(...) Otherwise, I need to maintain a bunch of code refs and figure out the right one to call, and then SUPER won't work as expected, either, so I need to pass in the original code ref in case you just want to modify existing behaviour. e.g., sub option_list { my $super = shift; my @o = $super->option_list(); sort \&some_funky_sort @o; } which is pretty ugly, too. If I don't provide for it, whether that be a singleton or a package or maintaining a bunch of extra coderefs, you won't be able to override things.
I suppose the other question is - will anyone really need to override anything? Perhaps not. Am I just overdesigning? It's hard for me to tell. Afterall, I wrote the original methods the way I wanted them to be, and maybe that's good enough for others. I may have a lot of Hubris, but not that much - so I assume people will want to tweak things, but without modifying my module.
In reply to Re^2: Design of a global-variable storage package
by Tanktalus
in thread Design of a global-variable storage package
by Tanktalus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |