Hi all, I'm really enjoying Dancer so far. I appreciate the effort everyone's put into it. This will sound silly to some, but for a long time with Catalyst I was always frustrated by the stash being a hashref since it was so easy to misspell key names. However, the data in the stash is often rather arbitrary that it makes a touch of sense. With the config, though, data is not arbitrary. It's defined when it's read and should generally be read-only. So I was annoyed when I wrote a test and the very first thing I did was misspell a hash key with the config. So here's what my tests look like now: use Weborama::RTB; use Dancer::Test; use lib 't/lib'; use FauxObject; my $config = FauxObject->new( Weborama::RTB::config() ); is $config->serializer, 'JSON', 'The config serializer should be JSON'; is $config->auth->username, '************', '... and we should have an auth username'; ok defined $config->auth->pass, '... and password'; And that outputs: t/config.t .. ok 1 - The config serializer should be JSON ok 2 - ... and we should have an auth username not ok 3 - ... and password 1..3 Can't locate object method "pass" via package "FauxObject::__ANON__4". Available methods: password, username at t/config.t line 16. # Failed test '... and password' # at t/config.t line 16. # Looks like you failed 1 test of 3. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests Basically, the config hash becomes a read-only collection of objects and if you misspell a hash key (method name), you get a sensible error message and a list of the available methods. Obviously this only works if the config can be represented as a hashref. If you have config keys which cannot be methods, such as "--foo" or something, you can still reach inside the object $config->{"--foo"}. Note that chaining hash keys works, too ($config->auth->password). Would this be a reasonable feature for Dancer's config? If an only if the top level config is a hashref, it's blessed as a "Dancer::Config::Object". It should be transparent for the end-user, yes? Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/
Hi Ovid and thanks for your input. Le 20 mars 2012 12:21, Ovid <curtis_ovid_poe@yahoo.com> a écrit : [...]
Basically, the config hash becomes a read-only collection of objects and if you misspell a hash key (method name), you get a sensible error message and a list of the available methods.
Obviously this only works if the config can be represented as a hashref. If you have config keys which cannot be methods, such as "--foo" or something, you can still reach inside the object $config->{"--foo"}. Note that chaining hash keys works, too ($config->auth->password).
Would this be a reasonable feature for Dancer's config? If an only if the top level config is a hashref, it's blessed as a "Dancer::Config::Object". It should be transparent for the end-user, yes?
Looks to be a very handy feature to have, indeed. Maybe we should provide that if the user's config request it? Like set strict_config => 1;
Hi, question : can the config still be used as a hash in addition to an object ? If yes then it's cool. Otherwise we risk to break things On 20 March 2012 12:21, Ovid <curtis_ovid_poe@yahoo.com> wrote:
Hi all,
I'm really enjoying Dancer so far. I appreciate the effort everyone's put into it.
This will sound silly to some, but for a long time with Catalyst I was always frustrated by the stash being a hashref since it was so easy to misspell key names. However, the data in the stash is often rather arbitrary that it makes a touch of sense.
With the config, though, data is not arbitrary. It's defined when it's read and should generally be read-only. So I was annoyed when I wrote a test and the very first thing I did was misspell a hash key with the config. So here's what my tests look like now:
use Weborama::RTB; use Dancer::Test; use lib 't/lib'; use FauxObject;
my $config = FauxObject->new( Weborama::RTB::config() );
is $config->serializer, 'JSON', 'The config serializer should be JSON'; is $config->auth->username, '************', '... and we should have an auth username'; ok defined $config->auth->pass, '... and password';
And that outputs:
t/config.t .. ok 1 - The config serializer should be JSON ok 2 - ... and we should have an auth username not ok 3 - ... and password 1..3 Can't locate object method "pass" via package "FauxObject::__ANON__4". Available methods: password, username at t/config.t line 16. # Failed test '... and password' # at t/config.t line 16. # Looks like you failed 1 test of 3. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests
Basically, the config hash becomes a read-only collection of objects and if you misspell a hash key (method name), you get a sensible error message and a list of the available methods.
Obviously this only works if the config can be represented as a hashref. If you have config keys which cannot be methods, such as "--foo" or something, you can still reach inside the object $config->{"--foo"}. Note that chaining hash keys works, too ($config->auth->password).
Would this be a reasonable feature for Dancer's config? If an only if the top level config is a hashref, it's blessed as a "Dancer::Config::Object". It should be transparent for the end-user, yes?
Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
use overload qw/FTW/; On Wed, Mar 21, 2012 at 7:46 PM, damien krotkine <dkrotkine@gmail.com>wrote:
Hi,
question : can the config still be used as a hash in addition to an object ?
If yes then it's cool. Otherwise we risk to break things
On 20 March 2012 12:21, Ovid <curtis_ovid_poe@yahoo.com> wrote:
Hi all,
I'm really enjoying Dancer so far. I appreciate the effort everyone's put into it.
This will sound silly to some, but for a long time with Catalyst I was always frustrated by the stash being a hashref since it was so easy to misspell key names. However, the data in the stash is often rather arbitrary that it makes a touch of sense.
With the config, though, data is not arbitrary. It's defined when it's read and should generally be read-only. So I was annoyed when I wrote a test and the very first thing I did was misspell a hash key with the config. So here's what my tests look like now:
use Weborama::RTB; use Dancer::Test; use lib 't/lib'; use FauxObject;
my $config = FauxObject->new( Weborama::RTB::config() );
is $config->serializer, 'JSON', 'The config serializer should be JSON'; is $config->auth->username, '************', '... and we should have an auth username'; ok defined $config->auth->pass, '... and password';
And that outputs:
t/config.t .. ok 1 - The config serializer should be JSON ok 2 - ... and we should have an auth username not ok 3 - ... and password 1..3 Can't locate object method "pass" via package "FauxObject::__ANON__4". Available methods: password, username at t/config.t line 16. # Failed test '... and password' # at t/config.t line 16. # Looks like you failed 1 test of 3. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests
Basically, the config hash becomes a read-only collection of objects and if you misspell a hash key (method name), you get a sensible error message and a list of the available methods.
Obviously this only works if the config can be represented as a hashref. If you have config keys which cannot be methods, such as "--foo" or something, you can still reach inside the object $config->{"--foo"}. Note that chaining hash keys works, too ($config->auth->password).
Would this be a reasonable feature for Dancer's config? If an only if the top level config is a hashref, it's blessed as a "Dancer::Config::Object". It should be transparent for the end-user, yes?
Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (4)
-
Alexis Sukrieh -
damien krotkine -
Ovid -
sawyer x