In an imperative OOP language, an object can indeed be seen as a glorified dynamic data structure with its fields specification distributed between object ancestors (in the case of a class-based language, the ancestors being the class and its superclasses).
Not clear when do you mean by “object state”. Logtalk is a declarative OOP language (https://logtalk.org/manuals/userman/declarative.html). An object represents a theory (defined by a set of predicate declarations and definitions) and a hierarchy provides for theory extension. Mutable state, if that’s what you’re thinking about, is as an alien notion as it is in Prolog. Sure, you can use dynamic predicates, in the same way you can use them in plain Prolog or Prolog modules, to have non-backtracable state. But backtracable state means using logical variables as in predicates arguments (and object parameters).
Getting back on topic, when integrating Prolog with traditional, imperative OOP languages, Logtalk can work as a bridge by providing useful abstractions (see e.g. https://github.com/LogtalkDotOrg/logtalk3/tree/master/examples/document_converter) but, by itself, cannot solve the fundamental mismatch between declarative and imperative semantics. The good news is that we often don’t need to worry about mixed metaphors as separation of concerns can allow both sides to cooperate nicely.
It’s an ontological theory of knowledge – but, what i am wondering about is the ontological primitives – for example, ontology typically does not need a notion of implementation, or message or interface — what are these …
Guess you should add McCabe to your goggling, and the title actually is ‘Logic and Objects’.
If you cannot find it, I could share - maybe privately - my copy - it’s dead tree, but these days to provide a stream of photos of pages is much easier than in the past.
L&O introduced equational reasoning as well as OOP in Prolog. As Paulo said, it’s a good read.
The most rigorous treatment of OOP I’ve come across is the book Theory of Objects by Abadi and Cardelli that develops a formal language to describe intuitive (primitive) notions of how objects should behave. (The latter author worked on Modula-3 IIRC).
The prologue points out how there are problems with modelling objects in the typed lambda calculus.
I’m aware of the work by Abadi and Cardelli. Quite heavy on Mathematics. But their perspective is still, IIRC, imperative/procedural in the concepts that they model. Logtalk, being declarative (see the link above), the abstract OOP ideas are interpreted/materialized differently.
Logtalk was not created from an ontology perspective (if I understand your question) but from a software engineering perspective (thus the materialization of concepts such as protocol/interface, implementation, message, …). An object is a theory in the sense that is defined by a set of predicates and that you query it (through message sending) and the answer depends on what is true or false for the object (which may be standalone or part of a hierarchy).
Forget about state! That’s an imperative concept! Read the link on declarative OOP that I provided. Don’t get trapped in an imperative OOP mindset. OOP is more general than Java/C++/… materializations. Otherwise you will never “get” Logtalk or other systems such as L&O.
fred is an object. number_of_legs/1 is a (public) predicate. N is a logical variable.
You either change the definition of the fred object (but why make the elephant feel blue? ) and recompile or if you want to dynamically change at runtime fred color, that you can declare the predicate dynamic (and that, as in Prolog, would give you non-backtracable updates; but also, as in Prolog, use of dynamic predicates should be limited to when strictly needed).
It looks like i never understood Logtalk – or rather always misunderstood it.
It sounds like a Logtalk object-oriented description is completely static - and that is what you might mean with theory. Its analogous to a fact base in Prolog + predicates structured around object-oriented descriptive mechanisms.
And, its a software engineering technology because it aims to deal with complexity of computable descriptions through its various mechanisms.
Yet, state exists in form of dynamic structures threaded through calls …