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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,103b407e8b68350b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-04 07:56:34 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeed.cwix.com!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!spool0901.news.uu.net!spool0900.news.uu.net!reader0900.news.uu.net!not-for-mail Date: Tue, 04 Feb 2003 10:56:30 -0500 From: Hyman Rosen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030130 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Anybody in US using ADA ? One silly idea.. References: <1043938782.244443@master.nyc.kbcfp.com> <25ji3v8n915cnnnaqpjvm4f7i01a66r9pf@4ax.com> <1043949507.331484@master.nyc.kbcfp.com> <1044025336.3067@master.nyc.kbcfp.com> <1044033063.693737@master.nyc.kbcfp.com> <2b9s3vo3bbnaikqd6d4jpppfflfq2kbgfu@4ax.com> <1044278793.419261@master.nyc.kbcfp.com> <1044291655.564852@master.nyc.kbcfp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Organization: KBC Financial Products Message-ID: <1044374191.250359@master.nyc.kbcfp.com> Cache-Post-Path: master.nyc.kbcfp.com!unknown@nightcrawler.nyc.kbcfp.com X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) NNTP-Posting-Host: 204.253.250.10 X-Trace: 1044374192 reader0.ash.ops.us.uu.net 22319 204.253.250.10 Xref: archiver1.google.com comp.lang.ada:33772 Date: 2003-02-04T10:56:30-05:00 List-Id: Dmitry A. Kazakov wrote: > What is the type of a pointer/reference? "Pointer to OtherType"/"Reference to OtherType" > You have just started and already you have two sorts of citizens: > objects that are pointers and objects that are not. Yes, so? Obviously, as soon as you define any static type, you will have objects which are of that type and objects which are not. > How your definition would answer a very simple question whether a > pointer to A is a subtype of A? It will answer "no"? Pointers are never (OO) subtypes of anything. > What if some new language or even Ada, would push this idea further > and make all type operations transparent for pointers? Then there would be an implicit dereference of the pointer before the operation is applied. There is no reason to impute all of the operations to the pointer itself. > Not every object can be accessed through a pointer. Correct for the usual definition of pointer on typical hardware. > Your definition is inconsistent with that. No. > If I did not define an access type, then I lose subtyping relation? Not exactly. If you are not using a pointer or reference to an object, then you are simply using the object itself. Then you know its actual most-derived type, and its full set of available operations. If you invoke an operation of one of its base classes, then when the compiler calls that method, it will pass in a pointer to the base subobject and then you are back in pointer-land. In C++, you get your pointers for free :-) > If the object is a bit in a packed array, then it is no more object? Correct. In fact, the C++ standard library specifies a specialization for vector that works that way, giving sub-byte access. This is universally considered to be a mistake. The reason to consider such bits as second-class citizens is for simplicity of implementation. You could force the definition of bit-level pointers, and classes that took only four bits of space and so forth, but that doesn't map neatly onto typical hardware, so the C and C++ approach is not to do that. If it messes up someone's abstract ideas, too bad. > Integer is a type. It is no matter whether it is primitive or not. To > be "practical", your theory should work for all types. I don't have a theory. If I write code that does operations on an integer, the compiler generates assembly language that does the work. > X * Ptr = 0; > Ptr->Foo (); There are semantic restrictions on pointers that make the above illegal. I can quote C++ standardese at you about when a pointer is derefernceable, but I don't see what that has to do with anything. > But not for your theory. FORTRAN-IV does no type checks. So you may > call, but the result is nonsense. May call /= substitutable. That's nice. Why am I supposed to care about FORTRAN? I don't have a theory. I haven't defined substitutable. > I didn't say that. I said that the idea that a type could be defined > by a set of operations used in some [generic] body, is a bad one, and > then it contradics to DbC, separating interface and implementation and > number of other principles considered valuable for software > development. That's a matter of opinion. The clear utility of this approach in C++ is an argument against your claim. I don't use DbC, it's not clear to me that meaningful contracts can be specified for complex tasks, and I don't care at all about abstract theories of how to program. I think that contracts have exactly the same problems as correctness proofs and similar ideas, namely that the statement of what you want is exactly as complex as the problem you're trying to solve, and therefore is exactly as likely to be incorrect as the program itself. > Huh, I remeber people claiming that it is tedious to declare an object In C++ there would also be the additional complexity of defining how a set of operations could be defined, because of all the overloading and implicit conversion rules. A simple "a + b" can mean a large number of different things depending oon the types involved. Whether that's good or bad, it is nevertheless an additional obstacle which prevents such "operation contracts" (C++ gurus call them "concept checks") from being required.