Searching a motivating example for upcasts

[Stefan Ram]

I lean towards siding with Chris, in that i believe there can be code
which is not a model. For instance, the

...re also is code which is part of the controller or the view.

SCNR

Of course, I agree that objects usually should /not/ be
/required/ to model real-world things. Sometimes this just
happens to be natural (appropriate), sometimes not. So it
cannot be a guideline.

For example, a printer driver is a kind of software
representation (proxy) of the real printer. That would
be an example where a close relation to a real-world
entity makes sense.

However, this does not mean that every analogy used for
teaching is misleading, just because it involves cars
or other real-world entities.

For example, what I like about cars is that they have the
interface-versus-implementation abstraction, that is, you
just need to learn one interface (the steering-wheel-
dashboard-gear-and-pedal interface) to drive many different
cars (brands, implementations).

 

[Stefan Ram]

?

»Sorry, could not resist« to intentionally misinterpret
the meaning of the world »model«.

output, if you like) is to produce a model -- for traffic analysis say. That,

Maybe that is where this idea comes from, given that the
earliest OO language possibly was »Simula« (a language
for simulation).

But I don't, myself, think that the Simula world-view is really what OO is

Now I see that you already mentioned Simula.

all. If there's anything that could be said to model a printer, it'd be the
common interface to printing provided (at least in Windows) by the OS --

Well, one can say »If a human had something he needed to be
printed 100 years ago, he went to a craftsman called a
"printer"; if a program needs to print something today it
"goes" to a specialist called the "printer driver"«.

specifically (in Windows) by GDI and its descendants. In Java one would look
to
java.awt.print for the equivalent, but interestingly (I would say "tellingly",
but this is AWT where good examples are not the unvarying rule) there is
nothing there which looks like a model of a printer. The principle abstraction
is a print /job/.

Ok, then »If a human had something he needed to be printed
100 years ago, he established a printing contract with a
craftsman; if a Java program needs to print something today
it establishes a print job with java.awt.print.«

Further, I'd require that for my object to be seen as
legitimately a model (in context) it must be that it's
because it acts (in some way) "the same" as the thing
modelled.

A »model of an entity« or »a virtual entity« to me is
something that has some properties of the entity or/and some
of its behavior, but not all the properties (usually just
those considered »relevant« and possible to model) and not
all of the behavior. This is shown on the cover of a book:

http://farm1.static.flickr.com/27/45274594_cef86aa062_o.jpg

.

[* The "M" in MVC is nothing but pure technical jargon -- a handy, but
near-vacuous, label for one part of the architecture.]

I knew this. That's why I wrote »SCNR« before. To indicate
that I was aware of the fact that this was just a kind of pun.

Wandering a little further afield, I think that the critical properties of
objects are autonomy, isolation, and coherence (and one can maybe throw in
polymorphism too). So, even if an object /can/ be seen as a model, that's not

Polymorphism actually is not a property of a single object,
but of a message dispatch, because the crucial point is that
the target object (and not even its class!) in a dispatch
does not need to be determined at compile time. Polymorphism
means that a variable can be the intermediate receiver of a
message and the actual object will be determined as late as
at runtime from the contents of this variable. So in the
moment, the actual receiving object is fixed, the
polymorphism is gone. Therefore, it is not a property of
any single object.

When I asked Alan Kay for the meaning of »OOP«, he kindly
replied:

»OOP to me means only messaging, local retention and
protection and hiding of state-process, and extreme
late-binding of all things.«

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

interface-as-contract (my preferred way of thinking about Java interfaces).

The contract would be the legal requirements for
the steering wheel, dashboard, gearbox, and pedals
of a car.

I don't think the car example captures that very well.

That's exactly why I wrote the OP, to find a
better example!

(Not unless -- as perhaps may be the case -- the major controls for
cars are fixed by legislation.)

I assumed so, but do not know for sure. It might depend
on the country.

 

[Stefan Ram]

does not need to be determined at compile time. Polymorphism
means that a variable can be the intermediate receiver of a
message and the actual object will be determined as late as
at runtime from the contents of this variable. So in the

Or, more generally, the receiver object can be determined
at run time as the /result of a calculation/.

This assumes that /at runtime/(!), there is something called
»a calculation«! (After all, an expression is an entity of
the source-code model.) How can this be, when there are
»only objects« (and messages)?

In a purely object-oriented language, such a calculation can
only be the result of another dispatch. So, when »m(o)«
denotes the result of sending »m« to the specific object
»o«, then this means, we can also dispatch »m'(m(o))«, that
is, send the message »m'« to the result of »m(o)«, which
is known only as late as run-time. (A language this pure
does not actually exist, since AFAIK even Smalltalk has
variables [e.g., parameters] which are not objects [but
keep references to objects]. But I do not know Smalltalk
enough to be sure about this.)

In a non-purely object-oriented language (such as Java),
such a calculation might also include reading from
variables, applying operators or calling static methods.

 

[Lew]

Maybe just words, but I don't see a printer driver as a model of a printer at
all. If there's anything that could be said to model a printer, it'd be the
common interface to printing provided (at least in Windows) by the OS --
specifically (in Windows) by GDI and its decendants. In Java one would look to
java.awt.print for the equivalent, but interestingly (I would say "tellingly",
but this is AWT where good examples are not the unvarying rule) there is
nothing there which looks like a model of a printer. The principle abstraction
is a print /job/.

A *model* of a print job.

Is the abstraction an actual print job? No, of course not. It's a model of a
print job. You code to that model to create an actual print job at run time..

I wouldn't use the word modelling[*] unless there's some useful sense in which
the object I have created is more-or-less isomorphic to (some relevant aspects
of) the thing that I'm concerned with. Also the thing that I'm modelling must

Which is exactly what happens in the print-job example.

 

[Lew]

Overstating it a little but I'd like to insist that my object is only
legitimately model, if I could replace it in my program with the real thing
(with appropriate plumbing, of course), and my program would be expected to run
normally (barring problems caused by aspects of the real thing that I haven't
modelled).

That's plumb ridiculous. When you model, say, a business process in a
program, you cannot put the business process in the program. When you model a
customer in a program, you can't put the customer in the program and have it
run at all, much less "normally". When you model a print job in an API to
control print jobs, you can't put a print job in the API - the concept doesn't
even make sense. The code is code - it's in a different domain from the thing
the code describes. Code is not a customer, a business process or even a
print job - it is, perforce, a model of those things.

The description is not the thing. The painting is not a pipe. Obviously. So
modeling is going on. Obviously. That you can run a program with the real
thing instead of code is an amazingly stupid concept.

 

[Tom McGlynn]

You shouldn't be such a namby-pamby.


I can't help it.  I went to parochial school.

I should have said, "Because it was mispieled?"

Alas, I'm afraid that even looking for it I can't see any evidence of
a joke here, dry or not. Nothing seems to be misspelt, not even
'misspelled'. Some
contributors to this news group do have a reputation for being just a
little picky
about grammar and spelling, but I'm sure that you aren't one of
them...

In any case Merry Christmas to all.

Regards,
Tom McGlynn

 

[Arved Sandstrom]

This mirrors my own experience as a self-taught OO programmer. As it
happens, the first project I attempted in an OO language (C++) was a
program that communicated with an ATM. I wasted a lot of time trying
to write classes to model the physical parts of the ATM -- card
reader, cash dispenser, printer, etc. -- and getting nowhere.
Eventually I figured out that what I was really dealing with was more
abstract concepts like messages, protocols, sessions, and state
machines. I started writing classes to model those instead, and then
things started falling into place. But the examples in the books I'd
read were not helpful; if anything they actively led me astray.

I've been experimenting with Data, Context, Interaction (DCI:
http://en.wikipedia.org/wiki/Data,_Context,_and_Interaction) for over a year
now, largely in Scala and a bit in C++, and without going into the details
here, I'm finding that (1) DCI helps me a lot in thinking about what should
be an object, and (2) now I concentrate on _objects_, not instances of
classes. With respect to point 2 I am not willing to completely abandon
classes and go with prototype-based OOP (Self, Lua, Javascript) but I do
find that something like Scala helps in role implementation and hence in
coding DCI.

I wish to stress that although I've looked at a number of third-party DCI
implementations (like Qi4J for Java) I am not really interested in them. I'd
prefer to use a language that makes this kind of programming natural using
first-class constructs, and not by having to import third-party code. But
certainly with a language like Java one can at least identify classes and
objects much better than what is often taught; I certainly agree with you
(Jim) and markspace. If it wasn't Vehicle, Car, Truck, Bicycle, Train, and
Helicopter, and Wheel, Engine and Transmission, then it was animal
taxonomies or trying to classify grocery lists.

AHS

 

[Stefan Ram]

So, in a nutshell, the print driver's job is /translation/.

You are right when you take the inside point of view
and look at the /implementation/ of a printer driver.

However, the client of the printer driver only sees the
interface: »driver.print( page )« will print the page.

To the client this is a feature of »driver«. He does not
need to know, how »driver« is implemented, that is, that
driver delegates to a »real« printer. To the client,
for all intents and purposes, »driver« /is/ the printer.

The doctor only cares about two interfaces,

Yes, that's a good example!