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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8591be732d0fce98 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada OOP alternatives? Date: Thu, 17 Jul 2008 12:45:09 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <462e0cf4-1d53-4918-b30b-dd3d8df90f1b@p25g2000hsf.googlegroups.com> <487d9636$0$6543$9b4e6d93@newsspool3.arcor-online.net> <6e5uq2F5g7n6U2@mid.individual.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1216313109 718 192.74.137.71 (17 Jul 2008 16:45:09 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 17 Jul 2008 16:45:09 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:Nxe5UTkOK5DiHpTEljv2VX5XmVU= Xref: g2news2.google.com comp.lang.ada:6924 Date: 2008-07-17T12:45:09-04:00 List-Id: "(see below)" writes: > On 17/07/2008 02:36, in article wccy741fg0z.fsf@shell01.TheWorld.com, > "Robert A Duff" wrote: > >> "(see below)" writes: >> >>> On 17/07/2008 01:05, in article wcc3am9gytt.fsf@shell01.TheWorld.com, >>> "Robert A Duff" wrote: >>>> I'd still rather eliminate private parts altogether. >>> >>> How would you do that while allowing ADT clients to access objects directly >>> (i.e. not via a pointer a la Java)? >> >> I'd have the compiler take a peek at the body when compiling the client. >> After all, that's what Ada compilers already do for pragma Inline. > > Good point. > That does induce a bit more compile-time overhead, though, as all clients > would have to be recompiled on every update to the body. That's why I mentioned incremental compilation. I find that all too often, I have to recompile the world because I changed a private part, or I changed a generic body. That shouldn't be the case. I shouldn't have to recompile the world if I add a new procedure to a visible part, either (which is tricky to get right in the presence of overloading and use clauses!). Unless computers get a lot faster than they are, any compiler needs at least two modes: debug mode -- fast compilation, poor optimization, good debugging production mode -- slow compilation, fast generated code, confused debugger In debug mode, I'd treat sizes of private types as dynamic (i.e. don't peek at the body). In production mode, peek at the body. And I'd redesign generics so they aren't semantically based on macro expansion. In debug mode, the compiler would not have to look at generic bodies when compiling clients that use the generics. In production mode, the compiler could duplicate code for some instances -- sort of like the way inlining works in Ada. Possibly the compiler could guess when to duplicate code, or possibly have a pragma to give hints, or possibly both. >> And I think incremental compilation can be a big win. >> In fast-compile mode, I might tolerate the "via pointer" way. >> It doesn't need to be a pointer into the heap, as in Java. >> >> We're just talking about the size of the type, really -- you say >> "access objects", but clients can't access the record components >> of a private type -- all they can do is declare objects and >> pass them around. > > And copy them. Right. But the compiler doesn't need to know the size to generate the code for copying. After all, we already have dynamic sizes: X : String (1..Read_From_Keyboard(...)); and ":=" works. "=" also needs to know the size -- again, not necessarily at compile time. > Yes, but to do that well, they need to know at least the size of the > representation. Right -- "do that well" = what I called "production mode" above. In production mode, the compiler would know the size (unless it truly is dynamic). But with incremental compilation, it still doesn't mean recompiling the world when that body changes -- only when the size actually changes. Representation clauses and pragma Pack present some interesting issues. ;-) >> Java, like many languages, doesn't even _have_ separate specs. >> (And it _still_ insists on pointers for almost everything!) > > I loathe the Java type system's incoherence. > >> So it's clearly feasible to have information in bodies used >> when compiling clients. > > Certainly. > > To what extent do you think that the (optical) visibility of the > representation in the Ada private part offsets a need to give the client's > programmer a more formal statement of the semantics of the ADT? I think the optical visibility is not a big deal. But I want all implementation details (including what's now in the private part) stored in a separate file from the visible part, so it can be managed separately in the CM system. I want to be able to ask "did the interface of so-and-so change since last week?". Suppose I need a package that does something different on windows vs. unix. Ideally, I'd like the interface to be the same, and hide the differences in the body -- i.e. have two versions of that body. But Ada forces some of those differences to appear in the private part, which means two copies of the spec file, which means it's hard to ensure that the interfaces are indeed identical. And it causes evil code duplication. - Bob