Re: SoA Vs OO

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

Date: Fri, 25 Jun 2004 18:47:56 +0100

"Joachim Durchholz" <jo@durchholz.org> wrote in message
news:cbfuo7$rgp$1@news.oberberg.net...
> I spy wrote:
> > "Joachim Durchholz" <jo@durchholz.org> wrote:
> >
> > Perhaps I'm not following you. Let me see if I understand: You have
> > several types T1...Tn which let says might inherit from one another
> > in an OO language. In an OO language, there would also be m methods
> > for each type (to keep things simple assume each type has the same
> > named methods).
>
> Agreed until here.
>
> > Corresponding to this You define m*n curried functions.
>
> No, not at all. I'd define n curried functions - I'm not interested in
> doing the other (m-1) functions to fill just a single list.
OK, I was taking the general case, supposing the other functions were of
interest - which is typical. Its not *often* you'll be using just one
function out of a class. But OK, let's just assume you're only interested in
the one function. And I see below that you consider the multi function case.

> > At run time you have a list of partially assigned functions
>
> Just for the record:
> These are called "curried functions".
> It's also a simple case of closures.
I wanted to stay away from that particular minefield. You know, whether or
not you need to be invoking lexical scope for it to be considered a closure,
etc.

> > (where one of the parameters represents the "object"), and you can
> > invoke each in turn, which knows what to do since it's carrying
> > around its object argument with it. If my understanding is
> > correct...how is this different from roll your own OO?
>
> Because that parameter isn't very "object-like" anymore.
> The list element can't invoke arbitrary functions on it. This can be a
> Good Thing or a Bad Thing, depending on the situation :-) [see below for
> some ramifications]
>
> > True you don't have to do a v-table lookup, but that's because you've
> > essentially done your own v-table assignment at the time you bound
> > the object to its associated function!
>
> You're correct about the v-table lookup - basically, everybody is
> dispatching somewhere. Pascal programmers do it using "case", OO
> programmers do it using dynamic dispatch, functional programmers do it
> using currying.
> The above situation is different, however. If you will, the list
> contains degenerate vtables - each of them can dispatch only to one
> single function.
>
> Now, if having a list of just one function is too limited, you can
> construct records of curried functions. And such a record is indeed
> functionally identical to a vtable - here it's indeed a roll-your-own
> vtable.
>
> There's one important difference though: in the OO world, these tables
> are generated at compile time. In the FP world, they are generated at
> hoc, at run time; this means you compose your sets of functions as the
> situation mandates, not according to the whims of the class designers.
Well, I could do all this roll-your-own stuff in my OO language too, but
frankly I'd rather have the compiler do it, and take my chances with good
class libraries. Frankly I cant think of too many occasssions when I've
needed to repeatedly combine just the one function of a class with one from
another. If you find yourself having to do that often its a sign of an
ill-designed class library that lacks coherence (Although the lack of
multiple inheritance in Java has hurt on occassion)

> This is deeper than one might think at first. For example, when
> implementing subclasses, you're often forced to implement tons of
> nitty-gritty little functions that aren't needed for the concrete
> application you have in mind, but you have to implement them anyway
> because the parent class requires them.
> In the FP world, I just write those functions that I actually need.
Again you need to use the right tools. Eclipse (and other IDEs) will
generate the class for you with all the inherited abstract methods stubbed
out. So if you don't want 'em, don't implement em (personally, I change the
default code generator to generate a "throw new NotImplementedException();"
just to be sure but that's just a matter of personal preference).

> > In addition, you can't take advantage of inheritance so you really
> > are forced to define all m*n functions. Yes, it does the job but it
> > hardly looks like a win to me.
>
> Typical FPLs don't even have inheritance, they use different mechanisms.
> They are most similar to C++'s templates (but better).
> I.e. you take an existing implementation, instantiate a few parameters,
> and you almost have what you want.
> It's more disciplined in a sense (because you can't wilfully override
> functions with something subtly different), yet flexible enough.
OK, I'll concede you the wilful overriding bit. That's a problem of a lack
of semantic typing in most OO languages.

> >>>> The advantage is: you don't have to inherit from a common
> >>>> "CanvasItem" superclass that may be polluting your namespace.
> >>>> [...]
> >>>
> >>> I am not sure what you mean by "polluting the namespace"
> >>
> >> If I inherit the CanvasItem class, my new subclass automatically
> >> contains all the stuff that was declared in the superclass, whether
> >> I want it or not.
> >
> > Well that goes back to the issue of whether your inheritance
> > hierarchy was appropriate to start with. Again think of the
> > WindowWithScrollBar class. If I add stuff to the Window base class,
> > then yes I would want WindowWithScrollBar to reflect that too. If
> > not, then add it privately.
>
> No, I didn't mean that.
> Say the Window class contains a GdiHandle member. It's private since
> it's doing very, very crufty internal stuff, so the subclass can't even
> access it.
> Yet when the subclass declares a GdiHandle member, it has a name clash.
And for a very good reason! if the base class introduced GdiHandler, there's
a goodly possibility that whatever code you had in your derived class may be
obsoleted. So it doesn't surprise me that it breaks your derived class.

> Particularly classes like Window tend to have far more than 100 members.
> Now that's a full namespace!
> (Been there, done that - I recently spent the three years working on a
> OO GUI library, which weighed in at a six-digit LoC count...)
>
> >> If the superclass is revised, it may acquire new machinery and
> >> hence new names. Any subclass that happens to use the same name
> >> must be rewritten.
> >
> > That's what refactoring tools are for...
>
> If refactoring tools were a solution, then namespace pollution wouldn't
> be a problem.
> Specifically, things get more difficult if you're the author of the
> subclass and the superclass is maintained (and changed) by somebody else
> - particularly if you get a new version of the library with all-new and
> all-changed internals.
> Things get even more difficult if you're the author of the superclass
> and forced to stick with the names you already used because most of the
> subclass authors don't have refactoring tools to begin with.

> (BTW I haven't heard of a *working* refactoring tools for C++ *g* - no
> surprise, the C++ semantics is very tricky, and any tool that does code
> modification at a large scale must "know" about the ins and outs of
> every detail.
> Of course, that's just C++, not OO in general.)
I stopped using C++ years ago. If enough people do that, it might just go
away. (Yeah right.)

cheers
-sri

> Regards,
> Jo

Relevant Pages

  • Re: SoA Vs OO
    ... In an OO language, there would also be m methods ... > Typical FPLs don't even have inheritance, ... >> WindowWithScrollBar class. ... > Yet when the subclass declares a GdiHandle member, ...
    (comp.programming)
  • Re: SoA Vs OO
    ... Live with them until I find a better language :-) ... running this with postcondition checking enabled gives us ... but it does have one advantage: if a subclass redefines the ... > Does that mean you don't care for Smalltalk? ...
    (comp.object)
  • Re: SoA Vs OO
    ... Live with them until I find a better language :-) ... running this with postcondition checking enabled gives us ... but it does have one advantage: if a subclass redefines the ... > Does that mean you don't care for Smalltalk? ...
    (comp.programming)
  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... That certainly explains why that kind of language feature ... >> and embracing OOPL class libraries with inheritance that they ...
    (comp.object)
  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... That certainly explains why that kind of language feature ... >> and embracing OOPL class libraries with inheritance that they ...
    (comp.programming)