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

Yes, I agree to your agreement. Do you have any proposal for "who owns the Factory" when Bod owns the "interface"/base-class and 3rd party develop different subclasses to it? Someone has to update the Factory...

  • Comment on Re^3: Designing multiple related modules

Replies are listed 'Best First'.
Re^4: Designing multiple related modules
by Fletch (Bishop) on May 13, 2021 at 19:50 UTC

    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.