[Config-loader] Config::Loader design

[Robert Krimen]

On Sat, May 2, 2009 at 11:41 AM, Clinton Gormley <clint at traveljury.com>wrot=
e:

>
> > Config::Loader::Plugin::
> > Config::Loader::Stack # Each read configuration gets pushed onto this
> > Config::Loader::Read::
> > Config::Loader::Read::Any (... using Config::Any)
> > Config::Loader::Read::General (... using Config::General)
> >
> > my $loader =3D Config::Loader->new
> > $loader->setup_reader('Any' =3D> { ... Any setup (name, _local suffix,
> > look at $ENV, etc)... })
> > $loader->setup_reader('General')
> > $loader->setup_parser('Substitute') # Does C::P::ConfigLoader style
> > substituting
> >
> > $loader->read({ ... A hash containing default values ... })
> > $loader->read( 'any:path/to/config/directory' )
> > $loader->read( 'path/to/general-style.cnf' )
> > $loader->read( 'general:unknown-extension.txt' )
> >
> > my $config =3D $loader->load # Does parsing and merging
>
> I would have approached this in a different way:
>
> My thoughts were:
>
> $config =3D Config::Loader->new({...} or [...]);
>
> where the hash ref or array ref would allow you to specify your above
> examples, but without having to call each step separately.
>
> so, eg:
>  - a scalar would represent either a filename or a dirname, the other
>    settings for loading a dir or file would be the module defaults
>  - a hash ref would allow you to specify particular differences from
>    the default
>  - an array ref would contain a list of scalars or hash refs (as above)
>    which would be loaded in sequence


Yes, these would be parameters to the reader (or source) objects. Kind of
like
a model or view in Catalyst.


>
> But actually, maybe they don't need to be exclusive at all. My method
> could be used for (optional) initial setup, and your method for any
> later changes.
>
> what do you think?


I think we're mostly talking about the same thing. I think you're jumping
ahead and trying to see how
we can inflate a Config::Loader object from a hash.  At this point, I'm
trying to figure out how the internals should
work.

It's kind of like Moose. Sure you can specify a class via a hash:

{
package =3D> 'Point',
attributes =3D> {
    x =3D> { isa =3D> Int, is =3D> ro },
},
methods =3D> {

distance =3D> sub { ... }
}

But it isn't always the nicest way to flesh something out:

package Point;

has x =3D> (is =3D> ro, isa =3D> Int)

sub distance {
...
}

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/config-loader/attachments/20090503/=
8d1b7e06/attachment.htm