in reply to Re: Implementing filters as callbacks / hashrefs / regexes
in thread Implementing filters as callbacks / hashrefs / regexes

Regexp::Assemble is a nice module, but it would mean loading several hundred lines of code to replace what I'm doing in 10. I'm providing the "list of regexes" option as a fallback for completeness, for those who don't want to write a callback coderef, but it comes with the proviso that it will probably be slower than the other methods.

I reckon that the other methods will probably get more use from those who are concerned with performance. They can always use Regexp::Assemble themselves - I'll add the suggestion into the docs.

thanks

Clint

  • Comment on Re^2: Implementing filters as callbacks / hashrefs / regexes

Replies are listed 'Best First'.
Re^3: Implementing filters as callbacks / hashrefs / regexes
by ysth (Canon) on Jun 17, 2007 at 09:22 UTC
    You seem to be assuming that loading hundreds of lines of code is a bad thing; can you say why you think so?
      Long answer...

      The module in question is Config::Loader, which loads configuration directory trees.

      It has a mechanism for merging local overrides into the main configuration tree, which currently consists of having a local.conf file at any point in the directory hierarchy. The values in local.conf are deep-merged with the main config tree at that point in the hierarchy.

      At the request of a user, I'm adding the ability to customise the load and merge behaviour, adding three methods:

      • skip => [ qr//, qr//... ] | { } | sub { }

        Used for skipping context specific config (eg don't load cron daemon config in the web server).

      • is_local => [ qr//, qr//... ] | { } | sub { }

        Does this file/dir contain local overrides? In which case it should be deep-merged instead of just loading it

      • load_as => qr/..(..)../ | sub { }

        What key should a given filename/dirname be converted to? For instance db-(dev.domain.com) should be loaded as the key db Alternatively, if load_as($local_override_file) returns '', then the deep merge is run on each key in the local file (like  '../$_' foreach key %local).

      What does this have to do with loading hundreds of lines of code? Well, these regexes do not need to be assembled hundreds of times during the process' lifetime, just at process startup.

      Config::Loader just loads config - it doesn't have to be all singing and dancing. I'm adding the above flexibility, but I'd like to keep to core module as small as possible. I don't want to add dependencies which aren't strictly necessary. The developer who uses Config::Loader is free to choose to use Regexp::Assemble to create regexes, but I don't think it needs to be part of the core.

      Clint