Re: Lahman, how ya doing?

In article <Fcsie.7688$n95.5995@trndny08>,
H. S. Lahman <hsl@xxxxxxxxxxxxxxxxx> wrote:
>Responding to Hansen...
>
>>>>I've read of differences of opinion on whether programming philosophies,
>>>>like OOP versus structured, can be mixed. It seems that few people think
>>>>they can or should. But I can imagine an OOP simulation included in a
>>>>very structured analysis program that, in an algorithmic fashion, sends
>>>>some parameters to Controller, pushes an event on to the queue to get that
>>>>going, and then gets a data set to analyze.
>>>
>>>I am definitely in the camp that holds that the paradigms can't be
>>>mixed. But that is voluminous forum thread material, so let's not go there.
>>>
>>>I will make two points, though. Remember that the OO approach grew out
>>>of simulation needs and some argue that Simula was the first OOPL. So
>>>the militant use of abstraction and flexible logical indivisibility in
>>>OO development is pretty much ideal for simulation.
>>>
>>>The second point is a reminder that awhile back I suggested (I think --
>>>hard to keep the threads straight) that all the heavy duty processing in
>>>the feedback loop that drives the controller and all the heavy-duty
>>>thermo to compute temperatures could be done outside of OO as realized
>>>code. That's because it is pure algorithmic stuff that is well-defined
>>>outside the scope of this problem. For that kind of thing procedural or
>>>functional programming is usually a better choice because it is
>>>computationally more intuitive one doesn't have to worry about the
>>>requirements changing once it works correctly.
>>
>>
>> I wasn't quite sure what you meant there. I had originally thought of
>> having some big do_control_action() member function, and saving all the
>> running sums and previous values as class members. I thought you meant to
>> just take that out of the class as an external function. But when you
>> have multiple controllers, each will have its own data sets of running
>> sums and previous values to manage, and that gets less OOPy.
>
>I assumed the feedback calculations were substantial (you mentioned
>filters and FFTs, as I recall). Even in a pure procedural setting that
>would require some degree of modularization. I am arguing here that one
>probably wouldn't provide that modularization via OOP; one would provide
>is using structured programming techniques. Then that would, indeed, be
>encapsulated in some do_control_action() method of a single object in
>the OO solution. That method might look something like:
>
>Controller::do_control_action()
>{
> // extract necessary attribute data from objects and
> // format it into some sort of data structure the
> // procedural solution needs as input
>
> // Then invoke entry point in linked procedural package:
> doIt(big_honking_data_structure_reference);
>}

I learned in comp.lang.c++ that should be

dolt(const big_honking_data_structure_reference&);

--
"The polhode rolls without slipping on the herpolhode lying in the
invariable plane." -- Goldstein, Classical Mechanics 2nd. ed., p207.
.