B
BGB / cr88192
Stefan Ram said:
I don't think this summarization is in conflict with Kay's description,
though granted his description is a little more in-depth.
so, taken this way:
everything is messages, well, to me this seems to imply everything is an
opaque API operating on some or another "object";
local retention and hiding of state, I agree, it is best not to have one
thing mucking around in the internals of another;
late binding, yes, this is why we have "objects", where an object holds its
own collection of methods/handlers/... (this just means not to base all of
ones' code structure around fixed-logic functions, as I see it).
one way of which to "approximate" this is bi-level:
split the codebase into a number of mostly-disjoint "components" which do
not share state (IOW: no shared globals), and communicate in a way defined
in terms of a more-or-less opaque API (I go as far as to generally dislike
sharing structs as well, although in a few cases it can be used to a
"greater good");
use "objects" which are accessed via a defined API, which may in turn simply
redirect to using internal vtables (I prefer to wrap objects in an API
mostly due to the fact that this better isolates the user of the API from
internal details of the object, such as how the vtable is laid out, and from
matters of having to manually deal with the possibility of NULL method
pointers).
technically, this amounts to something a little closer to CLOS-style OO than
Java or C++ style OO, but I personally find this acceptable.
it also need not result in the horrible nastiness which people accuse C of
having when people try to use it for OO, rather, this is more a result of
trying to naively pretend C is Java.
FWIW, a CLOS-style fits much better.
granted, it is a little less nice for an "object" to implement multiple
"interfaces", given one can't just cast the thing, meaning that, as a
general rule, there are not multiple-interface objects. also notable is that
this style does not implement explicit inheritence, usually leading to a
"greatest common factor" approach to API design (not that this doesn't
happened in "blessed" OO languages, where a class somewhat higher in the
inheritence tree often will end up with methods only used by a select few of
its descendents, ...).
but, it does not mandate the piles of particular practices usually accepted
as "OOP" by the people who often promote this term (actually, I can coin a
new term for these practices: "Java'isms"...).
one could even go as far as to try using these practices in C, allthough
probably many "OOP" supporters would recoil at the idea "but C is not an OOP
language", or such...
"one class per file" does not come up here, nor the requirement that
everything be organized into a taxonomical inheritence tree.
hell, programming is not natural biology, we don't need some grand "tree of
life" from which everything is inherited (actually, as I see it, this
actually runs counter to flexibility).
actually, these above two are the ones I take most issue with...
well, that and violating the core ideals of OO (such as keeping one thing
from digging in the internals of another), while still claiming it is
"proper" OOP.
to me, OOP does not mean:
this.someOtherObject.yetAnotherObject.someFieldWhichShouldBePrivate=42;
//magic constant indicating some particular state
stuff like this "should" be done via methods, as I see it...
either that, or people "could" stop taking the high ground and demeaning my
use of C...
but, alas, probably neither will happen...
then again, these sorts of experiences are possibly part of why I looked
some at the LLVM codebase and decided to keep well away. I don't know what
their actual practices are like in general, but code which looks like this
fills me with uncertainty.
not like I make the claim my code is exactly all that high either (actually,
some areas are fairly nasty...), but hell, at least I don't really have so
much pretense to claim code superiority...
If it all