[DBIx-Class-Devel] Branch cleanup

[John Napiorkowski]

>________________________________
> From: Peter Rabbitson <rabbit+dbic at rabbit.us>
>To: Discussion of DBIC development <dbix-class-devel at lists.scsys.co.uk> 
>Sent: Friday, December 14, 2012 10:49 AM
>Subject: Re: [DBIx-Class-Devel] Branch cleanup
> 
>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>
>
>

I guess the only way to solve this is some sort of API / style writing guide, but I doubt given the makeup of the Perl community this will happen anytime soon.  I think even for our project it would be really hard to figure out a consistent guide to writing our APIs and interfaces. 

>
>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
>
>_______________________________________________
>DBIx-Class-Devel mailing list
>DBIx-Class-Devel at lists.scsys.co.uk
>http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class-devel
>
>
>