From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!) Date: 1997/02/14 Message-ID: #1/1 X-Deja-AN: 218837397 Sender: pcg@cassin.dcs.aber.ac.uk X-Disclaimer: Warning - Sender not verified References: <32E7E08A.3079@parcplace.com> <32E8BCE3.3029@calfp.com> <01bc0a1e$faed8ce0$c318b993@jarvisb> <5covaj$l0@boursy.news.erols.com> <5dmj1v$jhk@news1.ucsd.edu> Organization: Prifysgol Cymru, Aberystwyth Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object Date: 1997-02-14T00:00:00+00:00 List-Id: >>> "kennel" == Matt Kennel 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.