Re: SoA Vs OO

From: Cristiano Sadun (cristianoTAKEsadun_at_THIShotmailOUT.com)
Date: 06/30/04 

Date: 30 Jun 2004 11:15:40 GMT

Joachim Durchholz <jo@durchholz.org> wrote in
news:cbrohh$368$1@news.oberberg.net:

> Hmm... partly.
> Most of the time, I'm interested just in a small subset of the
> functions of a class. (Which makes me believe that the vast majority
> of classes is bloated beyond sanity. Which, again, makes me believe
> that the "everything should be in a class, and part of a datatype"
> claim often heard in the OO camp is bogus: sometimes, a set of
> functions is just a set of functions. It doesn't make sense to stick
> sin, cos, and ln into a data type, they are just functions that
> operate on a data type, and if OO languages had modules independently
> of classes, the classes would be less bloated... but I digress.)
>

Interestingly, OO can be seen as a way of carrying around a context in a
way that is cheap and usable automatically (by the compiler or runtime).

Note that the difference with, say, a procedural approach is only in the
nature of the context: for OO, it is the current class (or the system
for static-like methods); for procedures, it is simply the system.

"Everything should be in a class" is a way to say that, at applicative
level at least, everything has a context. An OO approach tends to
qualify that context explicitly, allowing the programmer to narrow it to
avoid errors and the compiler/runtime to detect more of the errors that
remain.

Even a set of library functions as sin, cos and ln does not exist in a
vacuum - their context is the language runtime, which in turn is an
abstraction of the platform. For example sin() on a certain platform may
give results different than on another (as opposed to its mathematical
counterparts), depending on the kind of algorithm with which is
computed.

So their perfect placing is in a class which represents the mathematical
capacities of the plaftorm, and of which as many instances exist as many
different mathematical toolkits we have - typically one. If this "one"
is an assumption of the language (as it often is), you will have a class
"Mathematics" with static-like methods or a library of similarly static
functions. But they still will be equivalent to methods of an (sometimes
implicit) "runtime" object.

Class bloating, on the contrary, comes from bad partitioning and classes
assuming too many roles - a situation where the context become much less
relevant than the specific method which is running, and we fall back to
a procedural approach.

The only "benign" form of bloating is that given by overloads - which
typically are only a way to make life easier for a class' client code
and count as a single method.

Relevant Pages

  • Re: SoA Vs OO
    ... nature of the context: for OO, it is the current class (or the system ... is an assumption of the language, ... "Mathematics" with static-like methods or a library of similarly static ...
    (comp.programming)
  • Re: the N word
    ... language into positive language because a vast majority of people have ... context) or anyone within earshot. ... If you want to continue to give white people that verbal power by being uptight about a word ... a nigger my question is always this: ...
    (rec.music.hip-hop)
  • Re: Female Intuition and Female Choice
    ... The statement on sharper sense is for instance, ... when the paragraph is read in context. ... but then I'm a man with meager language skills. ... learned skill, which women's gender role pushes them ...
    (talk.origins)
  • Re: Goedel - interesting problem?
    ... >statement of Godel's theorem as you'll get in nontechnical language. ... Probability is integral to inferencing in context, ... Explain the effect of Goedel's theorem to a music major, etc., who has ... If Torkel, read my reply to him just preceding ...
    (sci.logic)
  • Re: Test first as specification
    ... >>> the only valid input string is an infinite string of a's? ... Without some additional knowledge about the language we ... The context you mention below. ... correctness may be a matter of degree. ...
    (comp.object)