Do you program with entities that have names and you can talk about their interactions as if they had behavior of their own? If so, then you have objects.
Do you program with anonymous values without names independent of their structure, and you can then reason about them equationally? If so, then you have values and probably lambdas to plumb them through the program as they lack their own behavior (you can have lambdas over objects also, but we don't call that functional these days).
Does the language encourage you to think about named entities or does it encourage you to reasoning about values? Of course, not many languages beyond Haskell try to push you to reason about everything as values. And most OOP languages include some form of values these days (if not, we definitely program with immutable objects like points that lack names/identity and might as well be called values).
This is also why OOP is necessarily tied up with state: it doesn't make sense for an immutable container of something to even have a name as it can be only really be identified by its structure.
Well, it's been a while since I wrote CLOS for living - but I don't think I found it useful to regard behaviour as being tied to a single class - that sort of implies limited single dispatch whereas CLOS has the wonders of full multiple-dispatch so your behaviors are really attached to tuples of classes and other types.
An awful lot can happen between you calling a generic function and your method(s) being called - and pretty much all of it is customizable - hence the "CLOS is best thought of as being implemented in CLOS", which I think is from the AMOP.
Comments
Do you program with entities that have names and you can talk about their interactions as if they had behavior of their own? If so, then you have objects.
Do you program with anonymous values without names independent of their structure, and you can then reason about them equationally? If so, then you have values and probably lambdas to plumb them through the program as they lack their own behavior (you can have lambdas over objects also, but we don't call that functional these days).
Does the language encourage you to think about named entities or does it encourage you to reasoning about values? Of course, not many languages beyond Haskell try to push you to reason about everything as values. And most OOP languages include some form of values these days (if not, we definitely program with immutable objects like points that lack names/identity and might as well be called values).
This is also why OOP is necessarily tied up with state: it doesn't make sense for an immutable container of something to even have a name as it can be only really be identified by its structure.
Well, it's been a while since I wrote CLOS for living - but I don't think I found it useful to regard behaviour as being tied to a single class - that sort of implies limited single dispatch whereas CLOS has the wonders of full multiple-dispatch so your behaviors are really attached to tuples of classes and other types.
An awful lot can happen between you calling a generic function and your method(s) being called - and pretty much all of it is customizable - hence the "CLOS is best thought of as being implemented in CLOS", which I think is from the AMOP.