http://www.perlmonks.org?node_id=11132549


in reply to Re^3: Designing multiple related modules
in thread Designing multiple related modules

Hmmm . . . that's a good question; I was mostly thinking of this as the namespace being controlled by the factory author and not an open namespace with 3rd party implementors.

Maybe some sort of registry/plugin system that new subclasses could ask to be added to and/or be automatically added to if present in some special namespace but that (admittedly very handwavy vague idea) would be all I can come up with off the top of my head. Were my arm twisted I'd look to Java-land and see what sort of approach they take there (and some large grains of salt as well since it's not necessarily going to translate 1-to-1). I think there's stuff like how log4j handles this sort of thing similar problems with runtime specification of logging providers or backends that might provide inspiration.

Edit: tweaked l4j phrasing.

Edit again: Slightly (marginally so) more concrete thoughts: Mojolicious::Plugins might be another place to look for inspiration. Or Module::Pluggable, where the factory could consult each class in $self->plugins and if they have a register_social_class method call that (which returns maybe a list of the key it wants to be known by and a coderef to call to get an instance).

The cake is a lie.
The cake is a lie.
The cake is a lie.