Subject: Re: commit: UT_String
From: Dom Lachowicz (dominicl@seas.upenn.edu)
Date: Sat Jun 02 2001 - 16:45:53 CDT
> There's no way we're gonna carry around a vftable in UT_String. No way!
> Neither should it inherit any other class, especially not one with a
> vftable
> of its own.
This is flawed thinking. Just because a class was originally designed to fit
well into one situation does not mean that it cannot be adapted to better fit
into another framework. Subclassing with virtual functions is one such way of
achieving this functionality. I'm sorry if C++ doesn't give you virtual
functions for free (or by default) like Java does. They don't add all that much
bloat either, though.
> This class was designed to be lean. If we need that hashcode() function,
> it
> should be a freestanding function, overloaded on the UT_String type.
> That
> function should not return a size_t (if it was copied from some of my
> template->Abi-style converted hash map code I apologize for missing this
> in
> the conversion). It should return an unsigned integral value (like
> UT_uint32), and though size_t fits that bill it's not a size that is
> returned.
Ok, yes, size_t should -> UT_uint32. You're right here (size_t was used in the
template hash map though).
However, overloaded freestanding functions are a major flaw in C++, and
desperately show the problems that arise by not having some common anscestor
class and reek of C++'s C-based heritage. XAP_AbiObject strives to be this
anscestor class. Consider this scenario:
my way:
UT_Map::add (Object key, Object o) {
UT_uint32 k = key.hashcode();
m_pimpl->add (o, k);
}
your way:
UT_Map::add (std::string key, Object o)
UT_Map::add (const void * key, Object o)
UT_Map::add (const char * key, Object o)
UT_Map::add (Object key, Object o)
UT_Map::add (int key, Object o)
...
Is my solution easily extensible and flexible, not to mention clean? I think
so. Is the alternative? I'm of the opinion that it isn't. I won't even get into
the scenario of properly referencing and keeping track of pointers here... Sure
there is more than one approach to any given problem. Not all of them are on
equal footing, though.
> Remember, there is more than one way to skin a cat, err, to express an
> interface. It also takes careful consideration before adding vftables to
> some classes *especially if they have value semantics*.
You betcha. vftables and interfaces aren't bad things in and of themselves.
Interfaces are the best thing about an OO language - hands down. I fail to see
how hashcode() violates your "value semantics" argument. ref() and unref()
might, but only if you convince me of the below point:
> If the strings are to be ref-counted, inheriting XAP_AbiObject was
> precisely
> the wrong way to do it. It should be a property of the string class,
> where
> it stores a ref-count in the string buffer.
I fail to see the difference, but maybe that's just because I haven't given it
much thought. Please convince me that my way is wrong and yours is right,
because I'm a skeptic. All I see is a different place where the integer ref-
count is stored and no bad side effects arising from that.
Dom
This archive was generated by hypermail 2b25 : Sat Jun 02 2001 - 16:46:11 CDT