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,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: milod@netcom.com (John DiCamillo) Subject: Re: Choice of OO primitives in Ada95 Date: 1996/02/21 Message-ID: #1/1 X-Deja-AN: 140533675 sender: milod@netcom16.netcom.com references: <4g2f8v$15lc@watnews1.watson.ibm.com> organization: NETCOM On-line Communication Services (408 261-4700 guest) newsgroups: comp.lang.ada Date: 1996-02-21T00:00:00+00:00 List-Id: ncohen@watson.ibm.com (Norman H. Cohen) writes: >|> Tucker Taft wrote: >|> : ... The orthogonality of >|> : types and modules in Ada 95 can be a major advantage, >|> : gives the programmer more flexibility in structuring their system But Cardelli and Wegner [CW85] showed that the opposite is true: providing package types through existential quantification is *more* flexible than having typeless package values as Ada provides. It also simplifies and unifies the concept of Ada generic packages, which are almost package types, and allows package values to be treated as first-class values. To be sure, C&W based their analysis on a type system supporting first class functional values (not present in Ada), so their conclusions may not hold for Ada. However, I find it difficult to believe that the converse is actually true. >|> What flexibility does this approach offer over conventionally encapsulated classes? >1. It allows other forms of encapsulation and packaging, not involving > classes. We could have a package providing a nonextendible private > type for complex numbers, deferred constants zero, one, and i, and a > set of arithmetic operations. We could have a package providing a set > of constants. We could have a package providing a set of > higher-level auxiliary routines operating on a type provided by > another package, building on the primitive operations provided by that > package. I've seen people try to use C++ classes with no nonstatic > members for these other forms of encapsulation and packaging, and the > result is strained. "Strained" in what way? _D&E_ [Stroustrup94] mentions several minor problems with this approach, but seems to be considering using classes to wrap already existing global declarations. (btw, i'm not disagreeing, just asking for clarification) > That's one reason C++ has added namespaces, which > are like Ada packages. Sort of... Namespaces simply control name visibility, they are not an abstraction mechanism. Namespaces do not have private parts. Namespaces may be extended by multiple declarations. > But once the full generality of Ada-like > packages is available, the class program unit as an encapsulation > mechanism is redundant. Again, sort of. Why talk of adding a separate class program unit? Why not just extend packages to provide package types? That way, you have only one mechanism for encapsulation (the package) and packages become first class values, allowing for more flexible package declarations and increased code-reuse. [big snip] >Ada certainly recognizes a close relationship among packages, types, and >operations: If a package provides both a type and subprograms with >parameters or results of that type, those subprograms "belong" to the >type. (In the technical jargon, they are "primitive operations" of the >type.) >But a package is a module, not a type. Which is the whole problem, despite what the rationale tries to claim, IMHO. Ada, despite being a very type-centric programming language, has too limited a concept of types. >The unnatural modeling of >one-per-class data items as static "members" in C++ comes from an attempt >to force-fit the two concepts into a single construct. Not at all. The unnatural modeling comes from a lack of class values in C++. This same problem causes the awkward semantics of constructors and destructors. In other words, static members are a C++ problem, not a class problem. >-- >Norman H. Cohen ncohen@watson.ibm.com -- ciao, milo ================================================================ John DiCamillo Fiery the Angels Fell milod@netcom.com Deep thunder rode around their shores