On Oct 14, 2008, at 3:20 PM, Rick Gutleber wrote:
> Do you envision the policy as an actual object (i.e., class)?
The only other alternative that comes to mind is an enum and a switch
statement inside insert(con, policy), but I think you will actually
end up with multiple versions of insert(con, policy), if only due to
the differences between sequence and associative containers. So,
you'd end up duplicating code if you don't factor it out somehow.
Also, people may want to create their own policy classes. I don't
propose to solve everyone's problem with this, just most people's. :)
> would you want a whole hierarchy or just some separate classes?
Well, since it's going to be a template method, you can do duck typing
here: if the passed policy thingy looks like a policy object, it is a
policy object. No actual need for an abstract base class just to
satisfy C++'s static type system.
> I would naturally think of a class hierarchy where everything is
> derived from a vanilla Policy class, but honestly I don't see what
> purpose that would serve.
> I would give the InsertPolicy two members, an enum to represent the
> policy type (one of the 4 types you suggested), and an integer size
> value. Is the right track?
No. This is OO without the OO. It's the kind of ugliness you see in
code that has to mash two different type systems together. MySQL++
does it internally because it has to map the SQL type system onto C++,
though you're not supposed to see this. (Pay no attention to the man
behind the curtain.) I saw this pattern again just the other day in
an XML-RPC library, for the same sort of reason. It's popular in a
lot of C libraries that have to interface with OO systems.
Type-as-enum has no place in a system written entirely in a single OO
language. If you want a new type in an OO language, define a class.
As for the question of abstracting the size value, I guess you *could*
put it in an abstract base class, but I think you need a better reason
to create a class hierarchy than sharing an integer. Especially so
since each subclass will interpret the integer differently, and the
base class will have no use for it at all.
> The code seems to be organized with a single class in each file,
> which is the way I work, too.
Mostly, but not always. Exceptions and Options all get defined in a
single file each, because they're small and closely related. I think
this is another case where you want them together. We're probably
talking about ~100 SLOC.
> Would you want Policy class(es) to go in its (their) own file(s)?
Yes, but I would #include the header within the public section of the
Query declaration, so they get put into its interface. There's no
good reason to use these classes with any other class. The .cpp file
then defines the methods as Query::FooPolicy::method()...
> Or maybe the policy should be a private struct....
End-user code can't create policy objects if the declaration is private.
> Or, would you prefer me to use my own judgement and show you when I
> have something? ;-)
That, too, but be prepared for requests to go back and rewrite it. :)
You have read HACKERS.txt, I hope?