[DBIx-Class-Devel] Branch cleanup

[Brendan Byrd]

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.  How far do we extend and duplicate this
information?

Like I said in a follow-up email, it would probably look better just
to have a full example as a reference.  Too bad POD doesn't support
inline code with links, as that would really make the reference work
better.

> 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?

> I am moving this to historic_rejected/explicit_join_type, as per our
> previous conversation (it has tests in there that can be reused later).
> The concept of adding extra semantics *only* to custom relationship is
> architecturally unsound. For the proper way to do this - see [2] and the
> associated [3]

Yeah, I already read the IRC chat log about it to refresh my memory
before declaring it a reject branch.

-- 
Brendan Byrd <Perl at ResonatorSoft.org>
Brendan Byrd <BBYRD at CPAN.org>