>   Don't confuse modules with object-orientedness.

Hmm... I just checked online and I failed to find a definition of OO which
doesn't mention inheritance, so it would appear you're right.

The thing is, my understanding was always that the fundamental part of OO is the
concept of objects, not class inheritance, hence it being called "object"
orientation, not "inheritance" orientation. I thought it was about the concept
of objects as instances of a class with associated methods, interfacing with
other objects. Modular code doesn't have instancing, at least not the way I
understand it, it just groups together associated functions and has similar
private/public philosphy.

Ah heck, I know what I want to do, and I'm gonna do it. People can classify it
later! :)

>   So basically you will have interfaces (such as in Java) but no inheritable
> classes?

No, my point is I don't need inheritance, though I think my system will be quite
capable of doing it (I've not got as far as coding that yet).

>   The problem with that is that it forces code repetition

It only forces code repetition if I want to share code, which I don't. I want to
share interfaces. Though I'll probably write some form of inheritance anyway.

> (in other words, when you make code which handles objects of
> the type of a certain interface you just have to trust that the inherited
> class implements all of its methods properly; you can't force a certain
> method to work always in a certain way).

good point, though my specific problem will only implement methods for things
that are different between objects, I'm going to allow public variables in the
interface class so the code that's processing the objects can just perform
standard manipulations itself. Not true OO philosphy, of course, but it gets the
job done, which is after all why I'm doing any of this!

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message