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,92471489ebbc99c6
X-Google-Attributes: gid103376,public
From: Matthew Heaney <matthew_heaney@acm.org>
Subject: Re: Y2K Issues
Date: 1998/10/30
Message-ID: <m3vhl224uy.fsf@mheaney.ni.net>#1/1
X-Deja-AN: 406610110
Sender: matt@mheaney.ni.net
References: <dale-2910981230010001@dale.ppp.cs.rmit.edu.au>
 <F1LGL1.B6F.0.-s@inmet.camb.inmet.com> <71aejn$ped$1@nnrp1.dejanews.com>
NNTP-Posting-Date: Fri, 30 Oct 1998 00:39:20 PDT
Newsgroups: comp.lang.ada
Date: 1998-10-30T00:00:00+00:00
List-Id: <comp.lang.ada>

dewar@gnat.com writes:

> P.S. Why don't we want customers adding grandchildren of Ada -- simple, they
> would potentially depend on internal private parts of the implementation of
> these packages which we feel free to change without notice at any time!

But isn't that the whole point adding the (grand)child - to get at the
underlying representation of predefined types?

If I add a child to Ada.Calendar, and the vendor changes the internal
details of that package, then it's my problem!