Re: "private" copy of Tumbler/Context

Am 16.02.2014 um 16:29 schrieb Tim Bunce <[email protected]>:

> On Sat, Feb 15, 2014 at 12:07:13PM +0100, Jens Rehsack wrote:
>> Hi Tim,
>> 
>> I’d like to go one step further with Tumbler and Context.
>> For LMU (https://github.com/perl5-utils/List-MoreUtils) and MooX::Cmd
>> (https://github.com/Getty/p5-moox-cmd) I’d like to write the
>> distributed tests based on a bundled (inc/, not installed etc.) copy
>> of Tumbler & Co.
>> 
>> I think, seeing how it behaves in the wild will provide more
>> information. Also it allows to prove how good it can be adapted
>> (MooX::Test analogous to DBIT, but arranges tests with Mo, Moo, Moops
>> and Moose - and maybe for some hard guys, with
>> Class::Tiny+Role::Tiny).  For LMU I have to test the
>> all/any/none/notall with different tests for different implementations
>> - but have also to test xs/perl ($ENV{LMU_PP}) and all implementations
>> in one import etc. (read: several test plugins parallel with different
>> function names to call ...).
>> 
>> What do you think?
> 
> Sounds good.
> 
> I've renamed Tumbler to Data::Tumbler and polished it up a little
> (and made corresponding changes to both our tumbler.pl files).

git push eaten by stormy weather?

> I'm still not very happy about the interface between Data::Tumbler and
> Context, i.e.:
> 
>    tumbler(
>        \@remaining_providers,
>        $consumer,
>        [ @$path,  $name ],
>        $context->new($context, $variants{$name}),    <=== this
>        $payload,
>    );
> 
> Tumbler shouldn't be coupled to Context at all.
> 
> I think that should be either this:
> 
>        [ @$path,  $name ],
>        [ $context, $variants{$name} ],
> or
>        [ @$path,  $name ],
>        $code_ref->($context, $variants{$name}),


I still prefer entire OO API (I really like function objects as
C++ provides them, but I think expecting users overload their
classes will be a no-go ^^) - this is one thingie I want to play
with.

> The first means that $context wouldn't be an object any more (though
> individual settings would) so instead of calling methods on context,
> like $context->get_env_var($name) you'd call functions like
> get_env_var_in_context($context, $name);

Objects with an expected role being provided sounds more reasonable
to me. This would also allow to hide implementation details (on
both sides).

> The second option means passing in an extra code ref into tumbler().
> Either as an extra parameter which then has to be passed down through
> the recursion, or by making Data::Tumbler be a class that has the code
> ref as an attribute.
> 
> I'm leaning more towards the second as being an object is likely to have
> extra benefits.
> 
> 
> Returning to your suggestion of shipping Tumbler and Context a build-time tools
> in another module. Yes, that's worth doing.
> 
> Note that Tumbler and Context are not directly related to the test
> generation use-case.  So I think it would be a good idea to create another
> module which is aimed directly at supporting test generation and which
> uses Tumbler and Context.  That module would contain get_input_tests(),
> write_test_file(), plus a plugin mechanism (eg for dbd_dbm_settings_provider).
> 
> I suggest you start by creating a prototype of that module in
> sandbox/tim/lib and use it in sandbox/jens/tumbler.pl. Once you've
> something working I'll hack on it and adopt it in my tumbler.pl.
> 
> Sound ok?

I would start in the real life (but not doing releases) and see whether it
works as expected or not. I did a minor shot for MooX::Cmd related tests and
I think it can work in a limited environment (MX::Cmd, LMU are such) for
clinical trials ;)

Cheers
-- 
Jens Rehsack
[email protected]