🚀 go-pugleaf

In article <364@oracle.tc.fluke.COM> kurt@tc.fluke.COM (Kurt Guntheroth) writes:
>objects provide a method to "foo" themselves.  Naturally, if an object
>doesn't know how to "foo" itself, you get a message not understood
>error.  So here's the question...What has dynamic binding bought you?
>Don't you have to know pretty much what object you are sending "foo"
>messages to?  Don't you have to inspect something in the object or

All you have to know is that the object is foo-able; this is a far cry
from knowing the type of object.  In typical cases, this property will be
guaranteed by the flow of control in the program and shouldn't require any
inspection of the object at all.

Dynamic binding is a win when you need to deal with a range of different
objects that present a common interface. In such cases, dynamic binding
allows the objects to be managed in a generic way.  For example, imagine a
display manager handling a collection of screen objects. To redraw the
display, the manager can simply ask each object to draw itself. This can be
done without dynamic binding, but it becomes more complex. Note also that
with dynamic binding, the code to do this stays the same even if new object
types are added.

Dynamic binding is also a win where the object type will not be known
until run-time. An example is device-independent I/O, as for example in
the Unix system, where programs are typically written without knowing in
advance whether their I/O is to/from a terminal or a file. 

Anders Weinstein