🚀 go-pugleaf

In article <364@oracle.tc.fluke.COM> kurt@tc.fluke.COM (Kurt Guntheroth) writes:
>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
>remember when you created an object what type it is so you know it can
>receive a "foo"?  

If you write a function in C that returns a pointer, do you inspect it to
see if it is valid?  Part of the specification for a function  should be
that it returns a valid pointer.  Similarly, part of the specification of a
method should be that it returns an object that can understand "foo".  The
consequences of returning an invalid pointer are just as bad.

To be concrete, suppose the message is Draw.  Then you do need to know that
the object you send a message to can understand Draw, but you do not need
to know if it is going to draw a circle, rectangle, line, etc.

So your program has to be correct in so far as it never confuses graphical
objects with numbers, for example.  But other than that, it does not have to
keep track of the specific kind of each graphical object.  The runtime
system does that for you.

>Also, I have repeatedly heard the claim that dynamically bound languages are
>"just as fast" as static languages.  OK, make me a believer.  Who says so? 

Consider implementing a graphics editor in C or Pascal.  (I will take
Pascal, because I am more familiar with it.)  

In Pascal, you would define a variant record to describe the graphical
objects.  One field of that record would indicate the kind of object
(circle, rectangle, polygon, etc.)  Then you could define a Draw procedure
that does a CASE statement on the kind of object and calls the proper
graphics primitive.

Consider using an object-oriented version of Pascal.  You would define a
separate object type for each kind of graphical object.  Each graphical
object would respond to a Draw message and draw itself.

When the Draw message is sent, the runtime system, will look at the type of
the object and call the appropriate drawing code.

Internally, both approaches do the same thing.  They look at a tag on the
object, and select the appropriate piece of code based on the tag.  There is
no reason to assume that the object-oriented approach is going to be any
slower than the conventional approach.  (You can make the argument that the
object-oriented approach might be faster, because the runtime system would
have been optimized to do the lookup very quickly.  Some system, for
example, use a method cache to speed up the lookup.)

People who think of object-oriented programming as slow, are considering
Smalltalk in which every invocation can potentially require the run-time
look up.  In reality, it is possible to have a language like C++ or Object
Pascal in which the run-time lookup is only used when required by the
application.  

In addition, it is often possible to change a method call from being
dynamically bound to being statically bound.  For example, there may be
cases where you can deduce at compile time the type of an object and
statically bind a particular invocation.  (In Object Pascal, we have a
utility that can do this.)  

In this case, you pay for the overhead of dynamic binding only if you need
it.  The cases where you need dynamic binding are the same cases where you
would write a CASE statement anyway, so you sacrifice nothing.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET