Re: Philosophy of Polymorphism (was: Meyer(s) gets it wrong)

From: Michael Mendelsohn (keine.Werbung.1300_at_michael.mendelsohn.de)
Date: 02/27/04 

Date: Fri, 27 Feb 2004 09:43:34 +0100

Programmer Dude schrieb:
> There's an opportunity here to join two on-going threads....
> Michael Mendelsohn wrote:
>
> >> The driver is specific to an Epson printer or a printer that looks
> >> like an Epson printer.
> >
> > Still, it's late binding - you don't have to know about the exact
> > printer implementation when writing your printing code.
>
> In a sense. You're talking to a specific object--a driver--in a
> defined way (Epson talk), and that specific object talks to another
> specific object (XYZ Brand printer). I just don't see that as
> polymorphism--I'll try to explain precisely why below.

I am NOT talking to a driver - I am talking to an interface in the
original sense. My program (it'd have to be DOS, or it might run on a
non-PC home computer) assumes you hook an EPSON printer up to the
parallel interface. That the EPSON printer might actually be a STAR or
CANON does not matter; the program's written to expect the printer to
support EPSON operations in some way. Granted, the printer contains an
interface that takes the transmitted data and translates it into the
signals needed to drive the printer meachanism.
And yes, the printed letters might actually look different!

> I suspect we'll never "agree" on a gut level with each other's model,
> because we define our terms slightly differently. My contention, and
> I hope you're on board with this, is that both models are probably
> equally valid representations of the perceived reality.

Thus it's useful to understand both, and to understand when each is
useful.

 
> We agree on the elements of an abstract interface and late binding.
> A further element for me is that a polymorphic object is a *single*
> thing in a *single* location that *becomes*, at different times and
> depending on circumstances, *distinctly* different objects.
>
> For example:
>
> void Increment_It (IncrementableObject& obj)
> {
> obj.Incr();
> }
>
> You can pass any object that looks like an IncrementableObject
> to the above, and it invokes "Incr" on it. The actual object
> could be a numeric value or a list with a "cursor".
>
> The thing that strikes me here is that "obj" is a single thing in
> a single place that "becomes" different--sometimes very different
> (numeric object vs: list object)--objects under different
> circumstances (different call instances).
>
> The me, the model of a bunch of different objects "out there" that
> share a similar interface is NOT a polymorphic model. It just isn't.

You have a bunch of IncrementableObjects out there that share the Incr()
Interface, no?

> To me, they are instances of some class--perhaps a very abstract
> and complicated one, but instances all the same.

class IncrementableObject
    public
         procedure Incr(); virtual;

You'd need a declaration like that, and use an object derived from
thisclass, to use your code above, yes?

> To me, the MS webserver and apache *are* just instances of the class
> WebServer, which defines a specific interface (http). The class is
> a complex one with a LOT of "instance variables"--the "how" of a
> particular module, for instance.

Both servers do not share any code.
Thus, it is not a case of "instance variables", unless you consider the
code to be one. Actually, then I consider the molecules of your animals
to be mere "Instance variables";) turning stone to gold or a gnat into
an elephant are, after all, easy tasks for computer science! ;)

> Likewise printers. A trivial example, the vendor name and model
> and serial number are easily seen (at least I think so) as instance
> data that varies from instance to instance. I also see the deeper
> details of the implementation as a sort of instance variable.

You see everything as instance variable. Incr() code of a different
object? Just an instance variable!

> So, to try to summarize, it's the idea of a *single* thing dealt with
> in a *single* place--but which becomes different things--that is
> vital to my model of polymorphism.

Single thing = printer
Single place = program that outputs to printer
different things = different printers with different print mechanisms,
output quality, user configurability, etc.

> >> An example that sprung to my mind that would be hard to deny as
> >> polymorphic would be a virtual printer that dispatched print jobs
> >> to various real printers depending on the nature of the print job.
> >
> > A "virtual printer" as in "virtual class" does not exist - it's not
> > implemented; you talk to the _real_ printer as if it was the virtual
> > printer, and you don't need to know how the real printer is
> > implemented as long as it behaves to virtual printer rules.
>
> I can't tell if my example was understood, and that may be due to
> using the term "virtual printer". What I mean is a *single* thing,
> called a "Printer"--either on my desktop or on the network--to which
> I can send any printable object (document). That "Printer" then
> dispatches the job to an actual printer appropriate for the job.

I do not understand how that could be polymorphic.

It doesn't jibe with your "Incr()" example. In the Incr example, you
have different objects, and you can send each object the same message.
In the printer example, you have a single object (the dispatch printer)
that can receive different messages.
I view it as a collection of printers that offers as interface a
superset of the interfaces teh printer objects offer.

> Similar to sending a "speak" message to an Animal object and having
> that dispatch to the "became" object--a Dog or Cow, e.g.

There is no "animal" object; there are only actual dogs and cows.
And all of them can speak; there's no animal that'd be more appropriate
to speak than another one.

> > In your argument, you wait for me to give you an example "other end"
> > device, then point to it saying that it's only got one shape, so it
> > can't be polymorphous; and if I then substitute another device for
> > it, that doesn't count because they're similar. :)
>
> The disconnect is occuring, because (in my eyes) the dispatch is
> deliberate and intentional on your part. YOU surf from webserver
> to webserver.

How can the dispatch not be deliberate? What use is it if it isn't?
Anyway, the dispatch is not deliberate on the part of my browser; the
browser (and its programmer) have to make do with whatever server I
connect it to.

> YOU select a network device. That they share a
> common interface does not fully satisfy *my* polymorphism definition.
> Compare those examples to the "virtual Printer" example above.

Could you provide another example that is similar to your "virtual
printer" example?

Michael 

-- 
Feel the stare of my burning hamster and stop smoking!

Relevant Pages

  • Re: object system...
    ... supporting certain kinds of programming languages and formalisms that ... I am not aware of any way in which a prototype system can be implemented ... Interface is a poor-man's MI. ... like the programmer is fused with the program etc. ...
    (comp.object)
  • Re: Wordsearch:AI Insanity
    ... with the 'handwavium' data storage. ... what interface? ... gave the original specs to the company that hired the programmer ... filtering algorithms to take care of an erroneous command like that. ...
    (rec.arts.sf.composition)
  • Re: clisp, clsql and foreign functions: problems in windows executables
    ... 36 output registers, the serialization/deserialization being done ... A Calcomp plotter interface for under $20 instead of however many ... Plus, the PICs are *CHEAP*, only a buck or two each, and you can ... which includes as USB-attached programmer, a demo board (with LEDs, ...
    (comp.lang.lisp)
  • Re: Style and practice question: use of interfaces
    ... > I have a question for the Java programming community at large. ... programmer expects to have multiple implemetations of the interface, ... if a programmer feels that he or she will have ... of multiple implementations of a particular interface. ...
    (comp.lang.java.programmer)
  • Re: "Must instantiate controlled types at library level." Why?
    ... :>: dispatch table. ... When you write in a generic interface something like "type X is ", ... This requires either String or Wide_STring, ... I did say Eiffel not because it has MI. ...
    (comp.lang.ada)