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

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.
  • by jdhedden (5970) on 2007.11.26 13:25 (#59180)
    I'm disheartened to hear that you're having trouble with another programmer's code, and laying the blame solely on OIO. If you need help, OIO's POD references both the module's discussion forum [cpanforum.com] and the author's email: jdhedden AT cpan DOT org.

    While OIO's POD does discuss some of the advantages of using the inside-out object model, it also lists several more involved discussions on the matter including Damian Conway's book Perl Best Practices.

    OIO does provide methods for maintaining persistent data, but not directly to a database. However, I don't see why this would be difficult as it would only require two simple methods in the parent class: one to dump the object and store it in the DB, and the other to retrieve and reconstitute the object. Your comment of large SQL snippets all over the shop sounds more like implementation issues rather than a deficiency with OIO.

    With regard to the problem you're having with adding a new attribute, if you email me directly with the details (and perhaps an example), I'll do my best to help. Thanks.

    • I was having problems with O:IO because of it's frankly bizarre idea of requiring a user to provide regexen to match method/attributes, not to mention it's abuse of attributes syntax (yummy - whitespace sensitive code for no good reason).

      The number of places where it was needlessly complex and required copy and pasting where any sensible Class framework allows you to just specify the columns and have it DTRT.

      "OIO does provide methods for maintaining persistent data, but not directly to a database. However,
      --

      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;
      • Errm, DBIx::Class is an object-relational mapper, not a class framework. Criticising Object::InsideOut for not being an ORM is like criticizing perl for not being an editor. What are you even talking about?

        • DBIx::Class is also a class framework, same as Class::DBI and Class::Accessor - all of which are much easier to use and maintain than O::IO.
          --

          @JAPH = qw(Hacker Perl Another Just);
          print reverse @JAPH;
          • No, CDBI and DBIC are not the same kind of thing as Class::Accessor. You don’t write programs with CDBI/DBIC if they have nothing to do with a database, and you don’t stick non-database-related logic in your CDBI/DBIC classes either.

      • "requiring a user to provide regexen to match method/attributes"

        It's not a requirement - it's optional. Cut out the regexes, and your preformance will go up (probably significantly). The regex option is there to provide greater programming flexibility if that is desired. As with any feature, if it's not needed, then don't use it.

        "There is a great deal more to useful object persistence than a couple of SQL statements..."

        The requirement to tie your objects to a database was evidently something the or

        • Great :) I'd love to get rid of the regexen, but now they are there I don't know where they are used and would need to check - it looks to me that the original author cargo culted because the documentation wasn't clear enough - I certainly didn't find a nice simple example in the documentation.

          Class::Accessor and it's like allow me to specify my attributes in a single line, even Moose is less bizarre in how you specify attributes.

          I'm surprised people would choose to use O::IO in production code, I certainl
          --

          @JAPH = qw(Hacker Perl Another Just);
          print reverse @JAPH;