Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.object
Subject: Re: Type Systems and Dynamic Binding
Message-ID: <1989:Apr1206:29:5291@kramden.acf.nyu.edu>
Date: 12 Apr 91 06:29:52 GMT
References: <1594@optima.cs.arizona.edu> <3810@ssc-bee.ssc-vax.UUCP>
Organization: IR
Lines: 81

In article <3810@ssc-bee.ssc-vax.UUCP> dmg@ssc-vax.UUCP (David M Geary) writes:
>   Dan Bernstein claims to be able to implement dynamic typing on top of C:

Although I can implement and have implemented dynamic typing with a
suitable preprocessor over C, I did not make that claim in the quoted
material. Please read a quote before you paraphrase it.

> ]   Dan Bernstein
> ]]  David Geary
> ]]] David Gudeman
> ]struct {any object; void (*redraw)(); int (*ismouseover)();} *whatsinwindow();
> ]] NO.  This is *not* an example of dynamic typing implemented on top of C.

The original example in question was *presented* as an example of what
people do with heterogeneous (dynamically typed) lists. I responded with
the above structure to show how you implement the same thing in C, and
here Geary claims that the example was no longer an example of dynamic
typing. Sheesh. My response:

> ]With appropriate macros, I can use the above structure in the same way
> ]as someone using a dynamically typed language. In fact, with a
> ]reasonable preprocessor like AT&T's C++, I can declare the structure in
> ]the same way. I can get all the same type-checking (at run-time, too!).

What can one mean by typing, if not storage format plus type-checking
plus syntax? What I said here was that C++ has sufficient typing for
this example. Where do you see this claim of dynamic typing in C?

I'll answer your (trivial) question anyway, even though it has been
adequately answered by Chip and others in comp.lang.misc.

  [ sample problem ]

If you had been keeping up with the discussion in comp.lang.misc, you
would understand that giving the same name to variables in different
structures does NOT imply any magical connection between those
variables. In order to solve your problem as stated, you must make the
connection explicit, like so (as per my structure as above):

  struct redrawable { void *object; void (*redraw)(); } ;
  ...
  struct redrawable menu2redraw(struct menu *m)
  { struct redrawable r; r.object = m; r.redraw = m->redraw; }

(OO fans will note that I have just, in effect, defined a subtype.)
That makes the connection between menus and the redrawing you want to
deal with. Similarly for button and icon.

>  Developer A provides a function that returns a list of things in a window
> (things being buttons, menus, and icons).  Let's call the function
> getListOfThingsInWindow().

Wrong, wrong, wrong. There is no such thing in C as a list of buttons,
menus, and icons. My point in the heterogenous-list discussion was that
people only use heterogeneous lists as (a) union types; (b) objects, to
which a FIXED set of operations will be applied. What you mean is that A
defines a function to return a list of redrawables.

>  Now, developer B, given the header files and object modules defined above,
> processes the list, and displays all items on the list in a fashion similar
> to:
>    drawWindowThings(window)
>      window_t* window;
>    {
>      list_t*  wlist = getListOfThingsInWindow(window);
>      for(each object in wlist)
>        redraw the object
>    }

foo->redraw(foo->object); Done.

>   Admittedly, the same effect can be had (in C++) if developer A ensures that
> buttons, menus, and icons all have a superclass in common, such as
> windowThing which has a redraw method.

As almost everyone in the comp.lang.misc discussion realized, you can
also define a SUBclass as I just did. As Chip pointed out explicitly,
you can avoid tricky inheritance issues by having the subclasses *point*
to their parents, but I've written the above solution in C anyway.

---Dan