Perhaps, this is a blessing in disguise – from a relational prolog point of view – one is forced to thread logic state through predicate parameters.
Perhaps, the semantics of subclassing could be a composition of threaded states, say, like a “vertical” dict superimposed over the class hierarchy.
Although, perhaps in Logtalk all object state is backtrackable …
Just guessing here …
Dan
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 (Declarative object-oriented programming — The Logtalk Handbook v3.72.0 documentation). 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.
thank you for clarifying …
Could you elaborate more on what you mean by theory and extension of theory …
(from what i recall, theories are either predictive, or are “pattern” theories – i.e. more descriptive / interpretive – typically found in qualitative social sciences)
Perhaps a simple example of what you mean.
While waiting for Paulo surely enlightining answer…
IIRC L&O - an early attempt to OOP in Prolog, by Francis G.McCabe - gave this description:
an object is all we know it’s true about it
That’s an excellent definition indeed and quite accurate for Logtalk. Btw, L&O was a great inspiration for my work. McCabe book on L&O is a great read.
Examples are plenty 
A good starting point is the learning by examples guide at:
See e.g. planets, elephants, or prototypes . But we’re getting out of topic…
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 …
Dan
Googling L&O i get Law and Order the TV series – its probably not right … right 
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.
Thank you.
I found it on amazon and managed to order it – hopefully it will arrive sound and save in a month or two …
thank you,
Daniel
“Logic and Objects” (WorldCat) by Frank G McCabe
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.
Prologue
http://lucacardelli.name/Topics/TheoryOfObjects/Prologue.html
Main page
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.
The design patterns sample implementations are at:
https://github.com/LogtalkDotOrg/logtalk3/tree/master/examples/design_patterns
All the classical ones from the Gof4 book are there plus some other that are typical in logic programming and classical artificial intelligence. Some of the samples do use Logtalk’s message delegation mechanism ([]/1 — The Logtalk Handbook v3.72.0 documentation).
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).
thanks,
thats very interesting.
But, an object (i.e. an instance) is more than just a theory – it also has state … that, however, conforms with its theory … or spec (in SE terms).
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::number_of_legs(N).
N = 4
yes
what is N …
:- object(fred,
extends(clyde)).
color(white).
:- end_object.
what is white
and what if i now paint fred blue …
How is this conceptualized in Logtalk …
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 …
I will need to get my head around this some more 
Dan