re: object vs. model

[Raoul Duke]

hi,

"model predictions 'draw upon' other models, while object
manipulations 'push' manipulations of other objects."
from http://c2.com/cgi/wiki?ObjectVsModel

not sure i believe that about objects -- objects could be set up to
'draw upon other objects' and avoid any 'pushes'. (tho it leads to the
question of defining what good OO style is.)

sincerely.

[dmbarbour]

On Jun 26, 12:18 pm, Raoul Duke <rao...@gmail.com> wrote:
> not sure i believe that about objects -- objects could be set up to
> 'draw upon other objects' and avoid any 'pushes'.

That's dataflow or functional-reactive programming. It's a very good
style, but to implement it in OO involves a great deal of fighting
with the language and paradigm.

Consider http://c2.com/cgi/wiki?FourLevelsOfFeature

I advise that appeals to Turing Tarpit designs, Greenspun's Tenth
Rule, or working around the architecture via frameworks, is far from
the best way to understand and distinguish paradigms and language
architectures.

Besides, to say that X is Y by virtue of 'X can be set up to do Y' is
a fallacy that, if followed logically, says the Brainfuck language is
a Firefox browser. There may be some valid arguments against my
position in ObjectVsModel, but appealing to 'objects can be set up to
[...]' is not one of them.

Regards.

[Raoul Duke]

hm, it isn't that i see it as greenspunning or setting
brainfuck==firefox. it is that i interpret your note that objects push
manipulations upon others to be incorrect :-) since they push
messages, sure, but that doesn't mean they are always pushing
manipulations. messages are flexible enough to embody a range of
things, and one bad way of using them doesn't condemn the others. i
guess i see oo as being a superset of models, at the moment.

sincerely.

[dmbarbour]

On Jun 26, 1:31 pm, Raoul Duke <rao...@gmail.com> wrote:
> it is that i interpret your note that objects push
> manipulations upon others to be incorrect :-)

Ever hear of Heisenburg Uncertainty Principle? ^_^

Anyhow, exactly what an object does with a message once you send it is
outside the responsibility of the sender. If you, as a software
architect, lord over the software and impose functional or dataflow
requirements upon it, then you're simply not writing OO code anymore.

> it isn't that i see it as greenspunning [...]

OO isn't designed for dataflow, and isn't very good for it, so you'll
need to implement frameworks and analyses to make it happen
efficiently. Examples:
* signals and connections vocabulary will invade every object
* local cache values and cache-maintenance issues for disruption-
tolerance, data-delta isolation and framing, and reduced computations
* framing problems for incremental updates of intermediate caches
* concurrent dataflow to improve latencies (multiple CPUs)
* synchronized dataflow to improve predictability (e.g. two sources
into one object, more buffering and demand-driven architecture -
balancing of push and pull)
* cycle-analysis on object-graphs

Essentially, you'll be using OO as assembly components for dataflow
programming. And the stuff that would normally be compiled or added to
an optimizer in a 'real' dataflow language, you'll be implementing...
by hand.

That's not Greenspunning.

That's Turing Tarpit.

Don't confuse the two. ^_^

> messages are flexible enough to embody a range of things

The same can be said of any language primitive. One only needs
integers, right?

> one bad way of using them doesn't condemn the others

And one good way of using them doesn't condone the others.

> i see oo as being a superset of models, at the moment

To all appearances, the logic you have presented as reasons to "see oo
as being a superset of models" would apply equally to seeing brainfuck
in the same light.

...

I see message-passing and objects as a fine basis for distributed
programming, security, and modularity. But I'd not advocate writing
models, interactive UIs, and various other systems primarily using
OO.

Instead, I'd write them in another paradigm - like logic programming
or functional-reactive programming or a DSL. Then I'd write a compiler
that takes the language and produces an abstract object-graph, then
I'd pass the abstract object-graph a service-registry to hook the
correct live data-sources and such, and say 'Execute!'

If I must make a choice between Turing Tarpit and Greenspunning, I'll
choose Greenspunning... but I'll do it correctly to avoid the 'ad-hoc,
informally-specified, bug-ridden, slow' properties: fully develop the
DSLs or programs that go above the base language, and standardize them
to avoid dozens of competing, incompatible solutions.

[Raoul Duke]

>> it isn't that i see it as greenspunning [...]
> OO isn't designed for dataflow, and isn't very good for it, so you'll
> need to implement frameworks and analyses to make it happen
> efficiently. Examples:

> That's not Greenspunning.
> That's Turing Tarpit.

i suspect i'm just not up to speed on what you have in mind in the OO
vs. Model talk on the web page originally referenced. to me, when i
say that OO doesn't have to be "push" the way i understood it from
that page, i don't immediately think of / know enough to see it as
meaning "OO implementing dataflow".

you characterized OO as being push vs. Models which are somehow not
push, and i don't grok your distinction. model A calling upon model B
to turn gears and spit out and answer doesn't sound a lot different
than object A calling upon object B in some similar fashion.

> I see message-passing and objects as a fine basis for distributed
> programming, security, and modularity. But I'd not advocate writing
> models, interactive UIs, and various other systems primarily using
> OO.
>
> Instead, I'd write them in another paradigm - like logic programming
> or functional-reactive programming or a DSL.

on the whole i can certainly get with that.

sincerely.

[dmbarbour]

On Jun 26, 5:32 pm, Raoul Duke <rao...@gmail.com> wrote:
> model A calling upon model B to turn gears and spit
> out and answer doesn't sound a lot different than
> object A calling upon object B in some similar fashion.

Scale it up! Two is a too-small number to see complexity issues due to
mismatch, Raoul.

Perhaps an example will help. Based on a case mentioned earlier:

We want to model a candle burning in a closed room and make
predictions such as:
* How tall is the candle at a given moment in the future.
* How are the surfaces coated with wax and soot.

In addition, we also wish to tweak parameters and learn features like:
* How does the size of the room affect the rate of burning (e.g. due
to changes in ambient temperature - which may affect the wax, oxygen)
* How does the position of the candle in the room (e.g. near a wall or
corner) affect the rate of burning and the distribution of wax and
soot.
* What if we have more than one candle and put them near one another?
* What if we change the shape of the candle?
* What if we open one wall, a window, or the ceiling?
* What if the walls have a severe initial temperature differential?
* Does spinning the room make a difference?

Now, attempting to use Objects for modeling (as opposed to an assembly-
language for creating models that should really be glued together by a
compiler or interpreter) would typically involve:
* Creating a candle object, with an initial property like height.
* Adding a clock object, and hooking the clock object to the candle.
* Setting the candle up to modify its height and create soot-and-wax-
particle objects with each tick of the clock.
* Those soot-and-wax-particle objects need to go somewhere, so we add
a 'room' object and hook it to the candle so the candle knows where to
push the soot-and-wax-particle objects.
* Hooking room to time and soot-and-wax-particles so we can move them
around and coat surfaces.
* Add some oxygen-content to the room.
* Set the candle up as a consumer-of oxygen over time.
* Modify burning rate based on ambient concentration of oxygen.
* etc.

Note that as soon as two or three 'objects' are in a 'model', dataflow
is involved. Worse, it's totally interconnected: clock hooks to
everything, candle hooks to everything, room hooks to everything, etc.
The fact that these objects can 'call upon' one another doesn't help
reduce the complexity. As we add each element to the model (a spinning
room, a window, etc.), nearly every single behavior needs to be
updated.

If we wish to abstract the candle so we can use many different shapes,
that is possible, but the candle must still have dozens of 'hooks'
into its programming environment to obtain the information it
requires. This is a severe breakdown for using objects for modeling -
essentially an inversion on the encapsulation-of-data requirement,
each object calling upon all the other objects to make local updates,
and no reuse for any of these objects in a slightly different
environment because each new addition or tweak to the model now
requires hooking in ever more objects.

The complexity involved is one of mismatch impedence. We attempted to
use objects for modeling when, fundamentally, objects are the
antithesis of models. Where a model predicts or analyzes behavior, an
object dictates or synthesizes it. Where a model draws upon data and
other models passively and processes it implicitly via a common logic,
an object must actively request or attach to data sources and decide
how to process it locally.

If we used a modeling language for models - a DSL, or logic
programming - we could achieve composable models, allow easy derived
models, automatically derive which pieces are related and need to be
hooked together, and build the appropriate system behavior. All the

Objects aren't Models. They aren't bad assembly components for /
implementing/ models, though, so compiling a logic program into an OO
program isn't unreasonable.

> when i say that OO doesn't have to be "push" i don't

> immediately think of / know enough to see it as
> meaning "OO implementing dataflow".

You'll learn. ^_^

[astrobe]

Let's take a raw example.

I use everyday a C++ object whose purpose is to operate an UART, the
chip that is behind the serial port.

The object has methods to set the transmission speed, parity, stop
bits etc. These methods may write directly in the registers of the
UART or call the OS to achieve this set up, depending on the
implementation. There's also a method to send bytes to the other end
over end - that's the main purpose of the chip.
If I got it right, the object is indeed "projective".

But this object may also recieve bytes from the other end. Typically,
the object installs an interrupt handler, so that an auxiliairy
function may read the incoming bytes from the UART's register and put
them in a fifo buffer, so that they can be delivered when the user
calls the "read" method.
Serial communication also features "control lines", that is binary
signal lines generally used to perform flow control.

The object reads the bytes and the state of the control lines (set by
the other hand). It is then, if I'm correct, "reflective". For
instance, the fact that the CTS control signal is asserted and DSR is
off may reflect the fact that the other end is present, but not ready
to send (if it is a modem, for instance).

In this particular example of the UART object (but that's also true of
a wide variety of onboard and external peripherals), the UART seems to
be both "projective" and "reflective". I would add that it is
reflective because it implements a "model" of the state of the other
end.

I think the problem is that the linked page mixes carelessly OO
design, OO modelling and OO programming.

[dmbarbour]

On Jun 27, 5:35 am, astrobe <fduboi...@gmail.com> wrote:
> I think the problem is that the linked page mixes carelessly OO
> design, OO modelling and OO programming.

The linked paged discusses Objects and Models in a more fundamental
sense than OO.

And the "model" your UART implements is not the UART object, and
shouldn't be held within the UART object (though may be usefully
referenced by it when the UART is deciding behavior).

[astrobe]

On 27 juin, 19:50, dmbarbour <dmbarb...@gmail.com> wrote:
> On Jun 27, 5:35 am, astrobe <fduboi...@gmail.com> wrote:
>
> > I think the problem is that the linked page mixes carelessly OO
> > design, OO modelling and OO programming.
>
> The linked paged discusses Objects and Models in a more fundamental
> sense than OO.
>

Then this page needs heavy heavy heavy clarifications IMO, because it
starts with "in ObjectOriented approach...", seems to take a very
concrete approach ("objects are handled by imperative languages",
"manipulations to objects are used to make *real* changes", etc.) and
doesn't give a definition of what is named "object" and what is called
"model". It doesn't refer to the "WhatIsAnObject" and "WhatIsAModel"
pages on the Wiki, either.

Sorry, that'll be last words on this topic, because we've been off-
topic from the start here (wrt th PLD) I think.

> And the "model" your UART implements is not the UART object, and
> shouldn't be held within the UART object (though may be usefully
> referenced by it when the UART is deciding behavior).

Yes! My description was simplified and inaccurate. the "model" I talk
about is usually implemented in an other object - a "Modem" or
"Printer" object for instance - that owns the UART object, because the
semantics of the state of the control lines I talk about is often
defined by the peripheral we communicate with (RS232 is such a mess,
you know).

[dmbarbour]

On Jun 28, 2:57 am, astrobe <fduboi...@gmail.com> wrote:
> > The linked paged discusses Objects and Models in a more fundamental
> > sense than OO.
>
> Then this page needs heavy heavy heavy clarifications IMO, because it
> starts with "in ObjectOriented approach...", seems to take a very

The subject of the topic sentence was "the ObjectOriented approach to
encapsulation and data hiding". I have now rearranged it to
"Encapsulation and data hiding (as seen in ObjectOriented
programming)" to help clarify the subject to readers who somehow
manage to turn their brains off shortly after reading the word-phrase
'Object Oriented'.

[Raoul Duke]

> Perhaps an example will help. Based on a case mentioned earlier:

thanks for the message! i will be pondering!

[Raoul Duke]

> Perhaps an example will help. Based on a case mentioned earlier:

ok, i think i see more what you are getting at. thanks for the example.

i don't yet understand everything you are saying, or perhaps i don't
understand / agree with the terminology yet. i do see that, and have
before noticed and thought a little bit about, encapsulation can be an
impediment.

sincerely.