Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Wednesday January 28, 2009
06:47 AM

Are you using your objects, or are they using you?

[ #38356 ]

Want to have fun sometime? Take a moderately complex system, open up one of your tests which instantiates an object and put the following line in your test just after you've instantiated an object:

$DB::single = 1;

That sets a breakpoint so that when you run the test under the debugger (perl -d t/some_test.t), you can type 'c' and the code will run until it hits that line. So imagine this:

#!/usr/bin/env perl

use strict;
use warnings;

use Test::Most 'no_plan';

use My::ORM::Customer;   # ORM classes are great for this
use My::Test::Fixtures;
My::Test::Fixtures->load('customers');

my $customer = My::ORM::Customer->find({ id => 1 });
$DB::single  = 1;

Now assuming that your code has stopped just after the $customer object has been instantiated, type this in the debugger and be amazed:

m $customer

In the debugger, the 'm' command tells you which methods are available on an object and which classes they're from. I did this for a simple object we instantiate. It's for our ORM and it represents a table with 8 fields, two of which are only for auditing. 255 methods were listed. Two hundred and fifty-five. They are defined across twenty-seven classes. And frankly, I'm not convinced that this list is complete, but that's the debugger for you.

Just some food for thought.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ... and how many of those were from UNIVERSAL:: ? :)

    • via UNIVERSAL: VERSION
      via UNIVERSAL: a_sub_not_likely_to_be_here
      via UNIVERSAL: can
      via UNIVERSAL: isa

      The full list of classes involved:

      Class::Accessor::Grouped
      Class::C3::Componentised
      DBIx::Class
      DBIx::Class::Co mponentised
      DBIx::Class::Core
      DBIx::Class::InflateColumn
      DBIx::Class::Relatio nship
      DBIx::Class::Relationship::Accessor
      DBIx::Class::Relationship::BelongsTo
      DBIx::Class::Relationship::HasMany
      DBIx::Class::Relationship::HasOne
      DBIx::C lass::Relationship::Helpers
      DBIx::Class::Relationship::ManyToMany
      DBIx:

  • Well, if 255 methods/27 classes are too much for your taste, change ORM!

    DBIx::DataModel [cpan.org] will only cost you about 50 methods in 3 classes (the exact number depends on how many relationships there are between this table and other tables).

    (sorry, DBIC folks, I couldn't resist ...)

    • Well, I doubt I could push that through at work, but I suspect that I'd be inclined to go the SQL dictionary route. Still, just glancing at it, DBIx::DataModel looks interesting.

      • No no, no SQL dictionary, you want to look at Fey.

        • Ah, that looks lovely! And yes, better than a dictionary.

          • It is lovely! I have been using it for a while and it has worked out every bit as well as I had hoped for. Sometimes I had to change the shape of my queries a little to accommodate it, but I have yet to run into a wall due to the fundamental design. There were stumbling blocks in cases where I ran into corners that Dave hadn’t built out yet – f.ex. when I first started with it, it failed if you tried to join against a table alias, which I needed for my tag (as in “folksonomy”) joins.

            • I know this is rather irrational - but the thing that off puts me from Fey is that the connection is kept in a singleton. This leads to the need of not very DRY declarations: package Forum::Model::User; use Forum::Model::Schema; use Fey::ORM::Table; has_table( Forum::Model::Schema->Schema()->table('User') ); It could be just: package Forum::Model::User; use base Forum::Model::Schema; has_table( 'User' ) I am acustomed to the DBIC way of having a normal Schema object that keeps the connect
              • I’m talking only about Fey::SQL, not Fey::ORM. I don’t use Fey::ORM at all.

                But do to take up your concerns with Dave – he’s a reasonable guy.

                • I've already asked him about the possibility of shortening the declarations. The answer was that that it probably mean too much magic - which is, in my opinion, only the consequence of using 'magic' signletons in the first place. I will not ask him about getting rid of that - since I would not expect any productive answer - this is too basic design choice to change in the mid-work.
                  • Ah. Well, I am happy to remain blissfully unaware of these issues and to stick with Fey::SQL. :-)