Xref: utzoo comp.lang.forth:599 comp.lang.smalltalk:706
Path: utzoo!attcan!uunet!mcvax!ukc!strath-cs!glasgow!orr
From: orr@cs.glasgow.ac.uk (Fraser Orr)
Newsgroups: comp.lang.forth,comp.lang.smalltalk
Subject: Re: Dynamic Bindings (was Re: Forth Preprocessor)
Message-ID: <1678@crete.cs.glasgow.ac.uk>
Date: 29 Sep 88 15:27:56 GMT
References: <13613@mimsy.UUCP> <3492@phri.UUCP> <23378@wlbr.EATON.COM> <1642@crete.cs.glasgow.ac.uk> <498@umn-d-ub.D.UMN.EDU>
Reply-To: orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr)
Organization: Comp Sci, Glasgow Univ, Scotland
Lines: 73

In article <498@umn-d-ub.D.UMN.EDU> gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) writes:
>WAIT WAIT WAIT WAIT.  Just one minute Fraser.  While you have had some valid
>ideas before, this time I think you've made a mistake.  Why is dynamic
>binding bad?

There are some things for which a late binding is useful.  But general
dynamic binding is terible.  I want programs to be transparently clear
(or as much so as is possible) and dynamic binding is one of the worst
types of hidden dependency I know of.  Let me give an example.

declare a ; # Declare a name a, this is currently unbound

procedure b
  declare
     c ;   # Declare this as a local variable
  begin
    c=a ;
    Process (c) ;
  end ;

procedure d
  declare 
    A ;    # Misstype this, it is supposed to be 'a'
  begin
    a=12 ;
    DoOtherThings () ;
  end ;

(Appoligies, I would have written this in Smalltalk, but my Smalltalk is
not really good enough)

Now with this fairly straightforward typing error, we have produced a
virtually undetectable bug.  If 'a' is supposed to be bound to a
procedure that returns an integer, it will apparently become a procedure
that returns only 12 (only after procedure d has been called).  Now if a
is a string, since the bindings all change dynamically, this will set
off a chain of errors too large to comprehend!

Now I know that dynamic binding has advantages, but I think that if you
required explicit marking by the programmer that this identifier would
have a variable binding (perhaps even stating the set of possible values
that it could take) then you'd be onto a winner.  This is in fact the
approach taken in C++.  Where the binding is essentially static, but can
be made late by the use of "virtual" functions.

Let me reitterate.  Use the best tool for the job.  Static binding is
best in all cases except for its usefulness in inheritance.

[Stuff about how static binding is not good enough for an OO language
 but useful in a language with OO features, deleted]

I think that it has yet to be establised that object oriented languages
are the best thing.  I like object oriented features and use them
frequently, but I can't see why people have taken it to the extremes
that has happened in Smalltalk.  OO programming is a good idea, but use
it where it is appropriate.  Modeling integers as objects that accept
messages etc is inappropriate.  This should be modeled in the way in
which it is used, that is, as a mathematical object.

>BTW: I am currently playing with a modification to a Forth-like language
>that has a clean implementation of object-oriented message passing, written
>entirely in C for Unix machines.  Maybe I'll even finish it some day.

You might be interested to read "a User Interface Toolkit in Object
Oriented PostScript" by Densmore et al, inComputer Graphics Forum, vol
6, no 3, pp 171-179, Sept 87.  In which the authors describe an object
oriented feature they added to the PostScript language.

>Glenn Andreas

Regards,

===Fraser.