Maybe that is not the best place to put Query and ResultSet then? If I were to guess, I would have thought they were more kind of like "inner-classes", meaning classes that Object used internally, OR that they were subclasses of Object. However, if they are actually on the same "level" as Object, I would recommend mimicing that in your directory/namspace structure. Keep in mind that you are adding a top level namespace Whatever::, which maybe can hold Object, Query and ResultSet for you?
They are not really suited to being inner classes. Users create and use them directly. If you want to query a collection of objects, you create an instance of Whatever::Object::Query, and invoke its execute method, which returns an instance of Whatever::Object::ResultSet. You then repeatedly invoke that object's get_next_result method which returns instances of Whatever::Object subclasses.
At first glance, your suggestion to put Query and ResultSet at the top level sounds good, but upon looking at my larger collection of classes, you'll realize that there is a snag. I also have Whatever::Link, Whatever::Link::Query, and Whatever::Link::ResultSet. These two objects are used in two scenarios: you have an object and want to do lazy loading of relatives at some point after it was loaded; you are loading a large collection of objects and want them loaded with one or more sets of relatives so as to keep the number of queries down.
I suppose I could bring these things top-level by squashing their namespaces, e.g. Whatever::Object::Query becomes Whatever::ObjectQuery and Whatever::Link::Query becomes Whatever::LinkQuery. I don't like that, though...
Now that I think about it, maybe I have the components of my name spacing all backwards! This all might make a lot more sense if instead of Whatever::Link::Query and Whatever::Object::Query I had Whatever::Query::Link and Whatever::Query::Object. In fact, I think that's perfect... Each of those could probably benefit (though I'm not yet sure how) from a common Whatever::Query base class. Furthermore, I could then use the Object subdirectory strictly for subclasses of Whatever::Object. This fixes all of my quandaries.
Now, however, I've thought of a problem that I'm going to encounter when trying to make DBD specific subclasses of Whatever::Object, e.g. Whatever::Object::MySQL. The general paradigm of my system already involves users creating subclasses of Whatever::Object, with the stipulation that the subclass provides a get_table_name method which is used both for for schema querying and object loading/saving. For example, if you wanted to have a Foo object, you'd have something like...
package Foo; use strict; use base qw/Whatever::Object/; # decorator methods go here 1;
... and to create a Foo object you would just do
my $foo = new Foo();
... which would cause the "new" method in Whatever::Object to be invoked which would bless a thingy into class Foo.
As you can probably see by now, this makes things a little sticky... If I'm running in a MySQL environment, then what I really want Foo to be subclassing is Whatever::Object::MySQL, but certainly Foo should be DBD agnostic, knowing only about Whatever::Object and not its DBD specific subclasses. The only thing that jumps to mind right now is to have Whatever::Object::new to go ahead and bless the thingy into Foo, but to also reach into Foo's namespace and mangle its ISA array to have not Whatever::Object, but Whatever::Object::MySQL (or whatever DBD we're using). Am I crazy for even considering this? Is there a more elegant way of doing what I want to do?
In reply to Re^6: Auto-Increment and DBD Agnosticism
by skyknight
in thread Auto-Increment and DBD Agnosticism
by skyknight
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |