Re: SoA Vs OO

From: I spy (s_nedunuri_at_yahoo.com)
Date: 06/23/04 

Date: Wed, 23 Jun 2004 18:48:01 +0100

"Joachim Durchholz" <jo@durchholz.org> wrote in message
news:cb9701$4fd$1@news.oberberg.net...
> I spy wrote:
> >
> > How would you implement something like the Decorator pattern without
> > inheritance?
> > (WindowWithScrollbar, WindowWithBorder, etc all need to be Windows and
be
> > passable to any client that was expecting a Window)
>
> I create a set of functions for each object (tagged with record field
> names for efficient access). One function is for drawing the thing, one
> is for intersection testing (e.g. to test whether the mouse cursor is on
> it), one is for determining the reaction to a mouse click or keyboard
> input, etc. etc.
> I may even go so far as to build a new intersection testing function
> whenever the window is moved or resized.
> There is a separate set of functions for each window. Sure, they share
> most of their code; after all, these functions were created by taking a
> template function and instantiating it with some fixed values for some
> of their parameters. (FP implementations make good use of this kind of
> function creation to get the whole process efficient. The relevant
> techniques have characteristics that are quite similar to those of
> dynamic dispatch in OO languages: horribly inefficient when done
> naively, but decent enough if you know the tricks of the trade.)
I am somewhat familiar with the techniques, having tried to emulate OO in a
Lisp like language I once had the misfortune of using several years ago. The
key problem as you rightly point out is simulating dynamic dispatch or
virtual functions. I don't really buy the roll-your-own approach. Its tough
enough writing good code without having to write your own language support.
You could make the same argument that I could create my own stack frames and
while loops in assembly language.

> Now when I want to create a list of things that can be moved, I don't
> place the entire objects in it. I simply make a list of move-the-window
> functions - actually I can place any kind of function in it that has the
> right signature. Since functions are data in an FPL, they also have a
> type; the functions for the example list would have a signature like
>
> Real delta_x, Real delta_y -> List<<Canvas_Action>>
>
> The advantage is: you don't have to inherit from a common "CanvasItem"
> superclass that may be polluting your namespace. All you have to do is
> to implement a set of functions that do what you want. And if you don't
> need a moveable window, you don't even have to provide a dummy
> implementation :-)
I am not sure what you mean by "polluting the namespace"

> > Real type inheritance (which no language really supports with the
possible
> > exception of Eiifel) doesn't introduce any coupling that wasn't already
> > there.
>
> ... and Eiffel has type holes because it's overambitious with real type
> inheritance :-(
>
> > ie if I inherit Square off Rectangle then its because a Square *is* a
> > rectangle.
>
> Only if Rectangles are immutable.
> If they are mutable, the procedure
> scale (x_factor, y_factor: REAL)
> doesn't have a meaningful semantics in Square. You are forced to either
> conclude that neither type is a subtype of the other, to violate the
> Liskov Substitution Principle, or to accept that you work only with
> immutable data.
I am unfortunately too familiar with the is-a-square-a-rectangle discussions
that draggged on ad nauseum on comp.object 7 or 8 years back. Mutable
atructures do indeed complicate the problem so perhaps I should have been
careful and said *immutable*. Anyway this is getting OT. The point I am
addressing is that to say inheritance introduces coupling and is therefore
bad is misleading, since it ignores the coupling already present that a good
inheritance structure simply makes use of.

> Which brings us full circle back to functional languages where
> mutability is a less-used (sometimes even neglected) tool.
not a bad thing, in my opinion. Mutability is the source of many bugs

> Regards,
> Jo

Relevant Pages