http://qs321.pair.com?node_id=11117460


in reply to Re: Cor—An object system for the Perl core
in thread Cor—An object system for the Perl core

1nickt wrote (emphasis mine):

Your own mostly wonderful Test::Most is a great example of how a designer's assumptions that are baked in make things less than completely Perlish. RJBS decided that he would export methods named all and any by default from Test::Deep, then you implemented Test::Most in a way that disallows controlling the bundled imported methods. So now it's impossible to test code that uses a method named any, e.g. from List::Util, without fiddling with the symbol table to rename the methods Rik and you assumed everyone wants exported.

This is not true. Specifically, it's not true that "it's impossible to test code that uses a method named any" (nitpick: it's a subroutine, not a method).

First, you can fully qualify your subroutine name as List::Util::any to test it.

However, a better solution is to simply exclude Test::Deep via use Test::Most '-Test::Deep';. This behavior is clearly documented and has been in Test::Most for a decade.

Neither solution requires "fiddling with the symbol table."

  • Comment on Re^2: Cor—An object system for the Perl core

Replies are listed 'Best First'.
Re^3: Cor—An object system for the Perl core
by 1nickt (Canon) on Jun 01, 2020 at 21:11 UTC

    Neither does either proposed solution solve the problem.

    I have a class. The class uses a bundle module. The bundle imports List::Util::any into the calling package.

    I like to test my classes. I like to use Test::Most. If I use Test::Most with default imports I get an exception (under strictures).

    Instructing Test::Most to not import Test::Deep in order to avoid this collision means that I cannot use the other methods in Test::Deep that I require.

    Test::Most does not allow granular control over the exports of the modules it imports.

    That's a design assumption: the user will either want all of Test::Deep or none of it. It limits the value of Test::Most.

    I don't want to see similar design assumptions baked into Perl. No one set of assumptions can possibly meet everyones's needs.

    It would be a mistake to put Cor or any other OOP framework into the Perl language.

    Q.E.D.


    The way forward always starts with a minimal test.