Re: SoA Vs OO
From: Joachim Durchholz (jo_at_durchholz.org)
Date: 06/25/04
- Next message: JXStern: "Re: Service Oriented Architecture (SOA)"
- Previous message: John Atwood: "Re: SoA Vs OO"
- In reply to: I spy: "Re: SoA Vs OO"
- Next in thread: I spy: "Re: SoA Vs OO"
- Reply: I spy: "Re: SoA Vs OO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 25 Jun 2004 03:23:53 +0200
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.
> 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.
> (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.
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.
> 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.
>>>> 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.
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.)
Regards,
Jo
- Next message: JXStern: "Re: Service Oriented Architecture (SOA)"
- Previous message: John Atwood: "Re: SoA Vs OO"
- In reply to: I spy: "Re: SoA Vs OO"
- Next in thread: I spy: "Re: SoA Vs OO"
- Reply: I spy: "Re: SoA Vs OO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
