From: c89ponga@odalix.ida.liu.se (kand. Pontus Gagge)
Newsgroups: comp.lang.pascal
Subject: Re: Turbo Pascal 7.0
Date: 29 Sep 92 13:35:53 GMT
Distribution: comp.lang.pascal
Organization: CIS Dept, Univ of Linkoping, Sweden

pf@bilbo.bio.purdue.edu (Paul Furbacher) writes:
>In article <1992Sep26.071819.20697@rulway.LeidenUniv.nl>, 
>  jeroenp@rulfc1.LeidenUniv.nl (Jeroen W. Pluimers) wrote:
>> ... I'd like to have the following construction. 
>> 
>>    constructor TMYObject.Init;
>>    begin
>>       INHERITED init;
>>       { do own initialisation here }
>>    end;
>> 
>> That way, if you insert an object between some object and their partents,
>> you con't have to explicitly change all the ancestor calls.
>> 
>> This one is suggested by the ANSI group on Object Oriented Pascal and
>> I hope it will be implemented by Borland soon.

>Perhaps I'm slow to catch-on here but I see all kinds of problems 
>and only a narrow solution.  Convince me I'm wrong on the following 
>points.  

>0.  How often do you do this?  It's not too often that I've done this 
>    and it's hard to imagine that the situation arises all that often
>    to make it a necessary feature. 

*What*? Not often? A call to the ancestor's method only tends to appear in,
shall we say, just about every VIRTUAL method I declare. Judging from the
next two objections, it seems there is a misunderstanding somewhere (maybe
with me). All *I* ask for, however, is a pseudo-function returning the
ancestor of a given type, somewhat like the TypeOf on objects. This does
not help with existing, compiled, fixed-in-amber TPU:s; their object 
hierarchy remains unbroken; but it *would* help with maintaining object
libraries.

At the present, the only solution I've found is to declare a type
equivalency for every type, suffixing "Anc" to its type named, declaring
its immediate ancestor. E.g.:
  TYPE ObjListAnc_ = List_;
       ObjList_    = OBJECT (ObjListAnc_)
         ...
and using ObjListAnc_ (NEVER List_) to link backwards in ObjList_ methods.
Thus, if the hierarchy needs be changed (say, by abstracting some
functionality to a PtrList_ between List_ and ObjList_), only one 
declaration needs be changed.

The drawback of this scheme (apart from the need for iron discipline) is
that TD behaves oddly (when doesn't it?). It forgets about the name "List_",
and goes on to say that every such object is a "ObjListAnc_". Irritating.


Since everyone else is producing absurd wish lists for a turbo pasCal 7.0
(C pronounced with utter disgust), I might as well; and hope that those 
other, horrid suggestions never be taken seriously by Borland. Here it is
(in no particular order):

1) A predicate function IsAncestorTo(type1,type2) : Boolean. When used, 
   a simple parent-link tree of object types is included in the EXE-file, 
   which can be simply scanned. Why? To program defensively. I have a lot
   of IFDEF:fed code to do sanity checks and catch errors; I find this
   saves *enormous* amounts of debugging time.

2) Cut out that foolish limitation on the IFDEF namespace! For somewhat larger 
   programs (say, in excess of 50klines with libraries), the need for partial
   debugging becomes great. This is most easily governed by DEFINEs/IFDEFs.
   IFDEFs are also very useful for producing different-language versions,
   demo versions, variants in complexity and user level, and so forth.
   However, it seems that the namespace for this is considerably less than
   a hundred characters, or so (never checked, exactly). This is simple, easy,
   and should have been done in 5.0.

3) While I do not demand that the compiler produce absolutely stunning 
   examples of assembly mastery; some things TP produce are beyond belief.
   For instance, the function value return code (e.g. "mov [bp+something],ax;
   mov ax,[bp+something]"). 

   The "dead code removal" was a boon, but it is quite a bit less than 
   perfect. "IF False AND ExpensiveFunctionCall THEN DoALotOfWork;" is 
   coded quite "live" (I discovered this a few days ago, to my dismay; 
   a lot of never-activated debugging code has been shipped in sales 
   versions... Some tens of Kb:s in the EXE files.) 
   
   And I haven't had the energy to hunt it down exactly, but it seems that
   *every* VIRTUAL method which is not overridden in any child, and never
   is referred in any active  code, is nevertheless linked into the program. 
   Any ancestor's definition of the same procedure/function is, however, 
   thrown away.

4) The linking together of units that refer to each other in the IMPLEMENTATION
   section (via USES) is oversensitive. It complains of "circular unit
   reference" when there is a clearly hierarchical order to the INTERFACE
   USES'. The IMPLEMENTATION declarations shouldn't ever be considered.
   INTERFACE parts should by definition be compilable without any reference
   to anything else but its own contents, and that of the INTERFACE 
   declarations of the units that are referred in the USES. This *should*
   be easily fixable, unless there really *is* something the compiler 
   needs to know from the IMPLEMENTATION sections (in which case they ought
   to scrap the whole thing).

5) Include files should be closed directly when read; instead, they seem to
   be kept open longer, during the entire compilation of the INTERFACE,
   when appearing in or before the INTERFACE section. The compiler looks
   at unit A, opens its include file, decides it needs to compile unit B,
   opens its include file, and needs to compile unit C...until "Too many
   files open". It takes some heroic juggling of the order of units in
   the USES clauses to fix this; and it is not even possible for some
   IFDEFfed constructs.

6) There are still some bugs in the treatment of missing inherited
   methods; some errors are not detected. I haven't got the examples handy
   at the moment. Well, at least they fixed the TP5.5 bug that made the
   compiler curl up and die (not even CTRL-ALT-DEL:able...)

7) The local function/procedure parameter mechanism that TVision hacks should
   be cleaned up and made a part of the language, with some suitable
   abstraction for the BP pointers, and serious type checking.

8) Better type deduction. If you subtract two Word:s in an Integer
   context, the result should be negative if the second is larger.
   Not so in TP. Instead, the type of the subtraction expression
   is taken to be Word, so instead of the proper result, you get
   the result + MaxInt. This is a type of bug I *hate* tracking down,
   since it can remain hidden a long time. To get the proper result,
   one or both of the operands must be typecasted to Integer.
   Dangerous and stupid.

9) The ones who made TVision should be sent to programming school. It is
   impossible to make programs safely survive lack of memory: whenever
   TVision allocates something, it *immediately* uses the memory, without
   checking if the pointer was NIL. Horrible. The "memory pool" idea they
   suggest is just a way of making the bugs more insidious.

10)Now, *this* is not something I would recommend for everybody, especially
   not inexperienced ones. But since I'm dreaming anyway: CATCH/THROW-
   constructs, such as in Common Lisp (or like exceptions in ADA). We have 
   made some utilities for this in TP6.0, with a lot of ASM-hacking and 
   plenty of abstraction to hide the ugly details. It simplifies error 
   handling something *enormous*. That's one of the things I admire 
   about ADA: it recognizes that errors *will* occur, and simplifies 
   their treatment. However, to use something like this, strict discipline
   is needed in order always to protect allocations and suchlike.
   <If the above is gobbledygook to you, I recommend checking out these
    facilities in CL and ADA.>

Ah well, since the list must be finite, I might as well end it here. Not to 
say there isn't more, but these seemed to be the most urgent ones.
However, I do not much expect Borland to do anything of this; they seem 
to be much more intent on the C:ification of TP, such as the revolting
$X+ switch.
--
/-------------------------+-------- DISCLAIMER ---------\
| Pontus Gagge            | The views expressed herein  |
| University of Link|ping | are compromises between my  |
|                         | mental subpersonae, and may |
| c89ponga@und.ida.liu.se | be held by none of them.    |
\-------------------------+-----------------------------/
Newsgroups: comp.lang.pascal