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: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!) Date: 1997/02/16 Message-ID: #1/1 X-Deja-AN: 219205796 X-NNTP-Posting-Host: sabi.demon.co.uk X-Disclaimer: Contents reflect my personal views only References: <32E7E08A.3079@parcplace.com> <32E8BCE3.3029@calfp.com> <01bc0a1e$faed8ce0$c318b993@jarvisb> <5covaj$l0@boursy.news.erols.com> <5dmj1v$jhk@news1.ucsd.edu> Content-Type: text/plain; charset=ISO-8859-1 Organization: Home's where my rucksack's Mime-Version: 1.0 (generated by tm-edit 7.94) Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object Date: 1997-02-16T00:00:00+00:00 List-Id: >>> "tiggr" =3D=3D Pieter Schoenmakers writes: tiggr> In article pcg@aber.ac.uk tiggr> (Piercarlo Grandi) writes: piercarl> Consider: piercarl> class C // bounded stack [ ... ] piercarl> This defines a class and a type encapsulated within it. Now piercarl> suppose we just added something like the following two piercarl> procedures: piercarl> class C // bounded deque [ ... ] piercarl> void *get(); void put(void *) { .... } piercarl> is the second 'C' the same type as the first 'C", only piercarl> updated? To me they are completely different types, for they piercarl> have different semantics, as well as different interface. piercarl> Instances of one 'C' are not instances of the other 'C'. tiggr> There are (many, very) valid examples of adding methods to a tiggr> class, which do not change the semantics of the object. I and tempted to be flippant here, as I am occasionally :-) when reading this sort of "=A3$%^&* statement, and comment "think harder". Actually instead I will agree with you, by saying that this statement may well be regarded as being true if one considers that by adding any number of procedures computing the identity function to a class, the algebra it implements does not ``really'' change. But surely your statement clashes _badly_ with your subsequent example: tiggr> In the example, only adding a `print' method, with the obvious tiggr> functionality, would not change the semantics of the existing tiggr> stack objects. Nor would it create a new class. The stack tiggr> objects would just be able to print themselves. Here we have the fantastic notion that "just able to print themselves" ("just"!) computes such a ``minuscule'' function that the algebra implemented by the class has not ``really'' changed. This is profoundly wrong. Plese spare me illustrating the reasons why... Let me just state that I can hardly imagine altering a class in such a way that it does not implement a new algebra, except for the trivial cases (adding no-op procedures, rewriting a procedure but having it still compute the same function). Also, in some important way this is beyond the point: in most languages out there ``type'' equivalence is not based on equivalence of the denotations of two types, but on ``name'' identity (not even ``structural'' identity, for even this involves subtle problems). tiggr> Objective-C (at least the GNU and NeXT implementations) allows =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D tiggr> methods to be added to a class in a running program. NeXT's tiggr> runtime library allows method replacement. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is not quite the case, to put it mildly, and the underlined bits indicate why: some ``Objective-C'' *implementations* allow programs to ``reflect'' on their runtime support structures, and even to alter them; programs can add pointers to method *representations* to data structures *representing* classes, which is quite (!) a different thing from allowing the addition of methods to classes. I am not aware of any ``Objective-C'' variants (or any popular, non-research-only) languages out there that allow programs to do the latter, but perhaps I am just behind the times (actually on reflection FORTH allows just that, but arguably by blurring the distinction between the language and its representation, and arguably CLOS does too, but then I would not call CLOS a popular language). One reason is perhaps that research in self-modifying programs is not popular, for it is not easy. The ability to alter classes, or any other part of a program, at runtime involves a number of hard conceptual problems; they can be sidestepped, or at least so it might seem, by providing (useful) implementation hacks, which are however a way for language designers to pass the bucket for the solution of those difficult problems to the programmers that use the hacks. Note that even bits of research that seriously address representation and semantics issues, like the relational model(s), only provide hints towards handling things like schema evolution for databases; and much of the popular stuff out there that might allow to do that is based on seat-of-the-pants ``concepts''. This is sad, but then addressing maintainability concerns seems to win less sales and publish less papers than delivering ``new and improved'' features. :-) tiggr> [ ... Cecil and TOM may/may not allow hacking implementations or tiggr> rather their language-level constructs ... ] I am not sure either; they are mostly research-in-progress, and I have not used either.