Re: Test::Deep 0.108 and the future of Test::Deep
On 2010.10.16 3:29 PM, Fergal Daly wrote: > I tried to port this import statement to Perl but functions vs methods > makes a general implementation impossible unless you have knowledge of > the module being imported. However there's nothing stopping individual > modules adopting the convention. It's particularly useful if the > module exports a large and growing number of symbols. So I could > imagine the follwoing interface. > > use Test::Deep2 qw($deep); # import the "module" as $deep > > $deep->is_deeply($foo, $deep->set([1,2,3,4])); > > So no namespace pollution but still access to all Test::Deep symbols > with little typing. I'm +1 to using this sort of solution for all the fiddly little special comparison functions, but not the entire interface. Exporting test functions is fine, they're unlikely to clash and they get used plenty. Exporting ninety bazillion little helper functions with names that are likely to clash and only get rarely used... not so much. Huffman encoding. Exporting a $Deep which the user can use for $Deep->re or $Deep->superhashof sounds like a good compromise. -- Defender of Lexical Encapsulation
Re: Test::Deep 0.108 and the future of Test::Deep
On 16 October 2010 03:59, Ricardo Signes wrote:
>
> Tonight I uploaded Test::Deep 0.108. The changes made are very small, and
> should not affect anyone other than some edge cases in which it should be
> faster.
>
> Many of the open bugs relate to unfortunately named exports like "blessed" and
> "isa," and to behavior that should probably change but would break existing
> scripts. I'd like to improve the way in which exports are organized and
> generated.
>
> "use Test::Deep" would be equivalent to "use Test::Deep -v0" which would be
> the
> current set of exports. The new set of catch-all behavior, mostly the same
> but
> with "blessed" and "isa" renamed would be "-v1". Other exports could be
> grouped in other ways to get things like "use Test::More -objects,
> -containers"
> or something along those lines. Using Sub::Exporter would make this very
> easy,
> and would allow a lot of other tricks like getting all the exports with a
> prefix on the names. ("td_bag" instead of "bag" for example.) I'm not sure
> whether there will be general chafing at the new prereq, though.
>
> Another common complaint is the lack of clear docs about what is and isn't
> exported. I'd like to get the export situation cleared up before documenting
> everything, so this is more or less tabled.
>
> Finally, there's a bug that cmp_deeply($have, $want) should compare both parts
> of a dualvar. I think this is a mistake, and am likely to reject it with
> alternate ways to write that test. I am open to argument now, but I think
> it's
> pretty likely that I'll follow through with this plan.
One principle of Test::Deep is that the comparator (the second
argument) controls the comparison. So, if $want is a string and $have
is a dualvar then string comparison is what you should get. If $want
is a dualvar then it becomes a bit tricky because then it's not clear
which is the correct comparison (string is what happens today because
non-refs are compared using Shallow.pm which uses eq for defined
non-refs). Sticking with the principle, $want being a dualvar should
result in dualvar comparison. However at this late stage, that would
almost certainly break existing code so seems like a bad idea.
Right now anyone needing dualvar comparison can use all(num(23),
str("foo")). Adding a convenience function for that (or even just
documenting it) seems reasonable,
F
> --
> rjbs
>
Re: Test::Deep 0.108 and the future of Test::Deep
* Fergal Daly [2010-10-16 21:30]:
> One of the reasons I had no time for Test::Deep is that my
> day-job is python. While I spend a fair bit of time cursing
> python, I do not miss for one minute Perl's global namespace
> which drives the need for exported symbols. In python modules
> are objects themselves and so you place the module object in
> your namespace and access it's members.
The difference is that without doing so, you cannot get access
to a module’s symbols at all in Python. In Perl, if Test::Deep
is loaded, you can get to its symbols from anywhere by saying
`Test::Deep::is_deeply`.
Strictly and impractically speaking there is no need for im- or
exporting anything at all. It’s a matter of convenience only.
You could write something like this:
sub usesubs {
my $pkg = shift;
require Carp;
eval "require $pkg" or Carp::croak $@;
( map { no strict; \&{ $pkg . '::' . $_ } } @_ )[ 0 .. $#_ ];
}
and then
my ( $is_deeply, $set ) = usesubs qw( Test::Deep is_deeply set );
$is_deeply->( $foo, $set->( [ 1, 2, 3, 4 ] ) );
With Devel::Declare you could then even make that something like
usesubs Test::Deep is_deeply, set;
However.
Test::Deep is not the place for experiments in fixing Perl
conventions. It is not the place for experiments in improving
anything other than recursive data structure comparison, which is
the one thing the module is about.
Foisting your ideas about how Perl (or Perl culture) should work
on the users of one module who do not care about those ideas will
only disgruntle them without fixing anything in the big picture.
To improve something fundamental about Perl you must do it in
a way that can be packaged separately from any specific module.
To increase its hopes of succeeding, it should be usable with
all, or at least many, existing modules, so users can subscribe
to the idea without the ocean having to be boiled. Then you can
evangelise it as a general new way of doing things, and if enough
individual codebases adopt it, it will spread.
Modules are poor place for evangelism about unrelated conventions
in general, but I feel this especially strongly about Test::
modules with break-the-CPAN level adoption such as Test::Deep.
--
*AUTOLOAD=*_;sub _{s/::([^:]*)$/print$1,(",$\/"," ")[defined
wantarray]/e;chop;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis //
Re: Test::Deep 0.108 and the future of Test::Deep
On Sat, 16 Oct 2010 20:29:32 +0100, Fergal Daly wrote: > use Test::Deep2 qw($deep); # import the "module" as $deep > > $deep->is_deeply($foo, $deep->set([1,2,3,4])); Or, without requiring any special exported symbol: use aliased 'Test::Deep2' => 'Deep'; Deep->is_deeply($foo, Deep->set([1,2,3,4])); Sadly, the functions all then have to be written as class methods. hdp.
Re: Test::Deep 0.108 and the future of Test::Deep
On 16 October 2010 21:32, Hans Dieter Pearcey wrote: > On Sat, 16 Oct 2010 20:29:32 +0100, Fergal Daly wrote: >> use Test::Deep2 qw($deep); # import the "module" as $deep >> >> $deep->is_deeply($foo, $deep->set([1,2,3,4])); > > Or, without requiring any special exported symbol: > > use aliased 'Test::Deep2' => 'Deep'; > Deep->is_deeply($foo, Deep->set([1,2,3,4])); Looking at the module I wrote but didn't release, I find aliased in my SEE ALSO section :) > Sadly, the functions all then have to be written as class methods. Which would break all the current users. http://search.cpan.org/~ovid/aliased-0.30/lib/aliased.pm#Why_OO_Only? describes exactly the problem I hit. You can't make functions and methods available through the same symbol unless you know which is which. Also you cannot give access to variables etc so I just gave up, F > hdp. >
Re: Test::Deep 0.108 and the future of Test::Deep
On 16 October 2010 03:59, Ricardo Signes wrote:
>
> Tonight I uploaded Test::Deep 0.108. The changes made are very small, and
> should not affect anyone other than some edge cases in which it should be
> faster.
>
> Many of the open bugs relate to unfortunately named exports like "blessed" and
> "isa," and to behavior that should probably change but would break existing
> scripts. I'd like to improve the way in which exports are organized and
> generated.
>
> "use Test::Deep" would be equivalent to "use Test::Deep -v0" which would be
> the
> current set of exports. The new set of catch-all behavior, mostly the same
> but
> with "blessed" and "isa" renamed would be "-v1". Other exports could be
> grouped in other ways to get things like "use Test::More -objects,
> -containers"
> or something along those lines. Using Sub::Exporter would make this very
> easy,
> and would allow a lot of other tricks like getting all the exports with a
> prefix on the names. ("td_bag" instead of "bag" for example.) I'm not sure
> whether there will be general chafing at the new prereq, though.
One of the reasons I had no time for Test::Deep is that my day-job is
python. While I spend a fair bit of time cursing python, I do not miss
for one minute Perl's global namespace which drives the need for
exported symbols. In python modules are objects themselves and so you
place the module object in your namespace and access it's members. One
of the first things I did was port Test::Deep and I use it like this
import deep
deep.compare(foo, deep.Set([1,2 3,4]))
I tried to port this import statement to Perl but functions vs methods
makes a general implementation impossible unless you have knowledge of
the module being imported. However there's nothing stopping individual
modules adopting the convention. It's particularly useful if the
module exports a large and growing number of symbols. So I could
imagine the follwoing interface.
use Test::Deep2 qw($deep); # import the "module" as $deep
$deep->is_deeply($foo, $deep->set([1,2,3,4]));
So no namespace pollution but still access to all Test::Deep symbols
with little typing.
All implemented with a few lines of AUTOLOAD (excuse my almost
certainly broken code).
package Test::Deep2;
sub export {
# poke "Test::Deep::Module" into the caller's namespace
}
package Test::Deep::Module;
sub AUTOLOAD {
shift();
goto &{"Test::Deep::".$AUTOLOAD};
}
Of course this could be done without a Test::Deep2, something like
use Test::Deep -module => '$deep';
with a bit more cleverness in export(),
F
> Another common complaint is the lack of clear docs about what is and isn't
> exported. I'd like to get the export situation cleared up before documenting
> everything, so this is more or less tabled.
>
> Finally, there's a bug that cmp_deeply($have, $want) should compare both parts
> of a dualvar. I think this is a mistake, and am likely to reject it with
> alternate ways to write that test. I am open to argument now, but I think
> it's
> pretty likely that I'll follow through with this plan.
>
> --
> rjbs
>
Test::Deep 0.108 and the future of Test::Deep
Tonight I uploaded Test::Deep 0.108. The changes made are very small, and
should not affect anyone other than some edge cases in which it should be
faster.
Many of the open bugs relate to unfortunately named exports like "blessed" and
"isa," and to behavior that should probably change but would break existing
scripts. I'd like to improve the way in which exports are organized and
generated.
"use Test::Deep" would be equivalent to "use Test::Deep -v0" which would be the
current set of exports. The new set of catch-all behavior, mostly the same but
with "blessed" and "isa" renamed would be "-v1". Other exports could be
grouped in other ways to get things like "use Test::More -objects, -containers"
or something along those lines. Using Sub::Exporter would make this very easy,
and would allow a lot of other tricks like getting all the exports with a
prefix on the names. ("td_bag" instead of "bag" for example.) I'm not sure
whether there will be general chafing at the new prereq, though.
Another common complaint is the lack of clear docs about what is and isn't
exported. I'd like to get the export situation cleared up before documenting
everything, so this is more or less tabled.
Finally, there's a bug that cmp_deeply($have, $want) should compare both parts
of a dualvar. I think this is a mistake, and am likely to reject it with
alternate ways to write that test. I am open to argument now, but I think it's
pretty likely that I'll follow through with this plan.
--
rjbs
