Re: Creating subroutines on the fly

[artist]

While it is possible as mentioned, I like to prefer a library of sub routines with specific names, that you can just include in your calling program. It may be easier to maintain and can provide less fear of wrong-doing or less debugging.

[Tanktalus]

You extend this a bit, and you have what is called an "API". You extend it further, and you get a mini language.

IMO, the original post isn't quite screaming (maybe loudly speaking) for a mini language, but if robustness is an important issue, a mini language may be in order. Using eval is one thing, and may be great if all interactions to that column in the db is through a perl programmer. Using a mini language allows you to go the extra step and allow anyone to update it, assuming you have enough flexibility in your library of subroutines.

[skx]

If you're going to go the mini-language route Module::Pluggable seems like a good choice.

I came across it with this simple introduction a couple of days ago.

[hakkr]

hi you dont need to use eval although it is probably safer,

my $subref = sub {print "hello"};

&$subref();

[monsieur_champs]

artist wrote:

While it is possible as mentioned, I like to prefer a library of sub routines with specific names, that you can just include in your calling program. It may be easier to maintain and can provide less fear of wrong-doing or less debugging.

Fellow artist
I see this as a distributed library implementation. Would love to know about better ways of implementing this, so I can use this to my own projects.

Maybe the better approach would be to store and retrieve modules from the database, and overload use or require to correctly load your module from the database.

Anyway, I would love to read more about this approach, and about distributed shared perl modules.