Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[pcg@aber.ac.uk (Piercarlo Grandi)]

>>> "kennel" == Matt Kennel <kennel@lyapunov.ucsd.edu> writes:

kennel> I don't know for sure, but what about a system where a 'routine
kennel> feature' could be added to a class during the execution of a
kennel> program, so that at one point in time, an object of such class
kennel> would not be compatible with some interface (e.g. not ''type''
kennel> T) but at a later time the 'same object' (forbearing us the
kennel> common delusion that objects have identity :) ) would be
kennel> compatible with that interface.

Well, it's hard for me to contemplate such an option, for there are two
assumptions here that are pretty hard to agree with: that the interface
to a module is the ``type'' of an instance of the type encapsulated in
that module, and that one can alter the definition of a class and the
instances of the class as previosuly defined become automagically
instances of the new modified class.

Consider:

  class C // bounded stack
  {
    unsigned m;
    unsigned b,t;
    void *e;
  public:
    void *pop() { .... };
    void push(void *) { .... };
  };

This defines a class and a type encapsulated within it. Now suppose we 
just added something like the following two procedures:

  class C // bounded deque
  {
    unsigned m;
    unsigned b,t;
    void *e;
  public:
    void *pop() { .... };
    void push(void *) { .... };
    void *get();
    void put(void *) { .... }
  }

is the second 'C' the same type as the first 'C", only updated? To me
they are completely different types, for they have different semantics,
as well as different interface. Instances of one 'C' are not instances
of the other 'C'.

If one creates a batch of instances of the first 'C', and then changes
the definition of 'C' so that it looks like that the second one above,
one has not changed in any meaningful sense the type of the first batch
of instances; one has merely created confusion by giving the same name
to two different entities at different times.

The opposite seems a rather extraordinary assumption, that I think is
induced but not justified by the ease with which one can, in some
implementations, change the ``class pointer'' from an object to the
_representation_ of its class to point to a new class object.

  In some language implementations, e.g. typical ``Smalltalk''
  implementations, if there any such thing, objects that represent
  classes are held, quite amazingly, in (anonymous) variables (like all
  objects actually), and objects that are instances of a class are
  linked not to the object that represents it, but to a _variable_ that
  holds that object; this means that one can, in some ``Smalltalk''s for
  example, change the class object that is attached to that variable,
  and thus have an object denote a the representation of a class of
  which it is not the instance; such hackery does not amount to changing
  the ``type''/type of the object.

The common delusion that objects have identity in non actor languages is
not quite relevant.