in reply to Perl Entity Bean

You mention Class::DBI, but don't explain what about your idea is different. On a quick reading, it sounds quite similar. Can you explain the distinction?

Replies are listed 'Best First'.
Re^2: Perl Entity Bean
by rje (Deacon) on Dec 28, 2004 at 23:06 UTC
    Yes, it might do the trick just fine. Part of my unknowingness is because I'm trying to define exactly what I want -- in the Java world, there are magic libraries that people never really have to know about, and therefore relatively young or stupid Java programmers can do dangerous things (for example, Entity Beans can render useless a web service).

    But with Perl, we generally see more of the guts of packages, so my eyes always get a little glazed over when I'm browsing CPAN.

    Actually, Class::DBI looks like what I want. It says it creates the accessors/mutators, but it's not clear whether they're just get/set methods or (as it seems to imply) that it creates lvalue methods along the lines of
       sub column_name : lvalue { $column_name{+shift}; }
    
    Or am I just not reading it right?

    Rob
      in the Java world, there are magic libraries that people never really have to know about ... But with Perl, we generally see more of the guts of packages

      If you're talking about Class::DBI, then I have to disagree. The only thing you have to do is define the table structure. It handles all the SQL behind the scenes, as well as the creation of classes. And if you don't even want to define the table structure, there's Class::DBI::Loader, which reads it directly from the database. I'm not sure how much more magical you can get.

      If you're talking about Perl and Java in general, then, again, I can't agree. My experience says the opposite. I find Perl modules do more "magic" than Java libraries, on the whole. Perhaps you could convince me otherwise with some specific examples, but I digress.

      It says it creates the accessors/mutators, but it's not clear whether they're just get/set methods or (as it seems to imply) that it creates lvalue methods

      It's pretty clear to me that they're the argument-taking variety of get/set methods, rather than lvalues. Here's an example from the SYNOPSIS:

      my $cd = $artist->add_to_cds({ cdid => 1, title => 'October', year => 1980, }); # Oops, got it wrong. $cd->year(1981); $cd->update;

      Notice the call to year on the $cd object.

        Well, maybe it's the way packages are documented, or maybe because Perl is an organic effort, or maybe the official Java API documentation feels easier on my eyes. Or perhaps I feel this way because I have more experience with Java packages than Perl modules.

        In the example above, for instance, there is no method specifically declared "add_to_cds()" in package Artist. I wondered if someone wrote a package so ingenious that just relating Artists to CDs in a certain way would automatically generate methods like these; with Perl, you never know, I mean I don't see why it can't be done. But of course I doubt that this is the case -- but I knew right then that there was stuff implied in the examples that wouldn't be immediately obvious to me. I felt like I was left dangling a bit.

        And then I had to make the leap from seeing a method I know nothing about (add_to_cds()) do something that's not documented (it actually creates and returns a new CD). My assumptions are probably right (rule of least surprise meets DWIM and TMTOWTDI, right?), but I'm not completely positive -- the DWIM to TMTOWTDI ratio is low. Of course, a few lines later the example code shows that those assumptions are probably 100% correct, because of the reference to $cd passed back, and later manipulated. Nevertheless, I had to decipher the documentation. In other words, I needed documentation on the documentation, I needed more commentary. Actually, in-line comments would have been perfectly fine.