[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
To OO or not to OO?
- To: MCL <info-mcl@digitool.com>
- Subject: To OO or not to OO?
- From: Ken Tilton <71460.744@compuserve.com>
- Date: 05 Mar 95 19:16:15 EST
- Sender: owner-info-mcl@digitool.com
I am porting (OK, rewriting <g>) my sort-of expert-system app from straight C
to MCL.
I was all stoked to see what my app would look like in OO form, but now I am
getting cold feet. My worry is performance, especially in regard to generic
function dispatch.
I am comfortable with table-driven (data-driven) programming, and it just seems
to me my current "C" design--structures differentiated in behavior by a "type"
slot which in turn indexes into a global table of type-descriptors (so I still
get to write generic code)--would be a better way to go even in CL.
Now don't get me wrong. I like OO. My idea is to keep out of CLOS only the
critical structures on which the expert operates, but use CLOS freely
otherwise. Of course, once I get fluent in CL, is it possible I will find CLOS
more limiting than empowering?
[Boy, could that start a flaming thread! :) ]
1. Am I mixing apples and oranges? Can I use CLOS efficiently as long as I do
not over-populate performance-critical generic functions with methods?
2. Are things like slot access and instance construction about as fast with
CLOS and structs? (Assume for sake of argument only one level of subclassing
under CLOS, and no overloading (?) of slot-accessor generic fns.)
Ken Tilton
Missing Link Software