[DBIx-Class-Devel] Branch cleanup

[Peter Rabbitson]

On Fri, Dec 14, 2012 at 10:14:13AM -0500, Brendan Byrd wrote:
> On Fri, Dec 14, 2012 at 9:25 AM, Peter Rabbitson <rabbit+dbic at rabbit.us> wrote:
> >
> > pod/result_class had some stuff you said you will look into incorporating
> > (2nd paragraph in [1]). I pushed the branch back as pod/resultclass_leftovers
> > If you changed your mind (i.e. it does not look as a good idea) - re-delete
> > it.
> 
> Are you talking about the stuff in INITIALIZATION METHODS?  I dunno if
> this is the right form for this stuff.  There's table_class and table
> method descriptions that are pretty much the same as the ones in the
> individual documents.

Not... exactly. But fair enough, we don't really need to document the
travesty, since it is *about* to go away. See *currently* before you
call ->table your source instance does not really exist, and some of the
methods are *not in the symbol table yet*. Hence why at the time I
wrote the blurb in question. Since then I have an almost-working
replacement for the logic which is still backwards compatible (which
makes it hieniously complex, but at least it's absrtracted). This gives
me a kick to revisit and finish it.

> Like I said in a follow-up email, it would probably look better just
> to have a full example as a reference.

Aye, please kill the branch.

> 
> > Btw the use of parent there is silly - parent when used in a project
> > alongside base actually makes things slower, not faster (yes, I did time it).
> > Furthermore once parent.pm shipped base.pm was optimised to work quickly in
> > most common cases. So the current state of parent.pm is like like that of
> > local $_ - cute but useless idea ;)
> 
> See, this is the sh!t that pisses me off about Perl.  First, we are
> told to use @ISA.  Then we are told that it's old and we should use
> "base".  Then we are told that we should use "parent" because base is
> bloated.  Now, we are NOT told that parent is actually slower than
> base.  And frankly, all of this BS shouldn't have started in the first
> place.  Base should have been fixed, and parent should have never been
> created.  For that matter, @ISA should have never been recommended,
> either.
> 
> How the ^@#$ is a Perl programmer supposed to get some work done
> without having a close ear to the #p5p dev team?

This is a direct result of a "meh, this cruft is too complex, I can do
better" attitude. It is not just specific to perl the core, it is
endemic to CPAN as well. 

<rant>

Since this is a pet-peeve of mine, I shall give you one exhaustive 
example for posterity: Take for example a seemingly simple problem - 
testing of exceptions as strings.

Initially we had Test::Exception, which *happened* to appreciate the
potential pitfalls[1], and worked around them. However the workaround
turned out to be buggy, and it took a while to fix - specifically [2].

So now Test::Exception just works - great! Except in the meantime we
got Text::Exception::LessClever [3] motivated as per [4], and then
we got Text::Fatal [5].

T::E::LessClever specifically undid what Test::Exception took care
of and my repeated attempts to take this module off CPAN went
nowhere [6], [7].

Test::Fatal was "cleverer" - it sidestepped the issue by not
providing a throws_ok, just a lives_ok/dies_ok. I asked rjbs twice
to document "if you want throws_ok - use Test::Exception" - he did
not find it to be worth the trouble.

To illustrate - here is a throws_ok that appears to work but
does not:
perl -MTest::Fatal=exception -MCarp=confess -MTest::More=no_plan -e '
  sub throws_ok (&$;$) {
    like(&exception($_[0]), $_[1], $_[2]||() )
  }
  throws_ok { confess "unrelated crap" } qr/expected_exception/, "all seems ok..."
'

Yes, the synopsis of Test::Fatal does work, but have you seen a perl
programmer *not* trying to be clever? :)
perl -MTest::Fatal=exception -MCarp=confess -MTest::More=no_plan -e '
like(
  exception { confess "unrelated crap" },
  qr/expected_exception/,
  "all seems ok..." 
)'

And this is just one module
</rant>

P.S. For bonus points -
Q: Why doesn't Test::Warn support multi-line warnings?
A: Because this is how the author figured he'll work around the stacktrace
problem (tripple facepalm)

Cheers

[1] https://github.com/adrianh/test-exception/commit/23e5d844
[2] https://github.com/adrianh/test-exception/commit/2f6200a0
[3] https://metacpan.org/module/Test::Exception::LessClever
[4] https://metacpan.org/module/Test::Exception::LessClever#WHY-REWRITE-TEST-EXCEPTION
[5] https://metacpan.org/module/Test::Fatal
[6] https://rt.cpan.org/Public/Bug/Display.html?id=61863
[7] https://github.com/exodist/Test-Exception-LessClever/pull/1