TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Alexandre E. Kopilovitch" <[log in to unmask]>
Reply To:
Alexandre E. Kopilovitch
Date:
Wed, 7 Feb 2001 19:38:14 +0300
Content-Type:
text/plain
Parts/Attachments:
text/plain (60 lines)
>>Also, in C++ those facilities are regarded as a kinds of classes, which seems
>>to be rather artifical and misleading.
>
>I don't think that's true. Why should they not be considered as a kind of class?
>
>Ada implements an almost identical feature - consider:
>
>package PVC_Package is
>
>   type PVC is abstract tagged null record;
>
>   function op_1 (This : in PVC) return Integer is abstract;
>
>end PVC_Package;
>
>This is very similar in effect to:
>
>class PVC
>{
>   virtual int Op_1() = 0;
>}

First, I feel a considerable difference between "abstract" and "virtual": the
word "abstract" (for a type/class) says explicitly and clearly that the class
isn't a real class, but only a template for it, and therefore it cannot have
the instances. To assume that one need not be very familiar with Ada. But the
word "virtual" has no such strong character, it suggests a vague image of possible
substitution, and in fact it often associates with dispatching ("vitrual" vs.
"dynamic" in Object Pascal). And the meaning of the word "pure" in "pure virtual"
is entirely specific to C++, so one need to be rather familiar to C++, and
moreover, put himself to C++ context for a proper association.
  Second, as far as I understand, now Ada recognizes the "interfaces" as a
good feature in the language and will incorporate them in some future. This
follows from the Tucker Taft's messages in comp.lang.ada .

>I believe that it is Java that is artificially differentiating between a Class
>and an Interface.
Let's look at the history: initially we had callbacks within the procedures;
then we focused on the objects and classes - thus embedding the design issues
directly into the programming languages, and began to group callbacks into
the records - that way we got those "pure virtual classes". So, the pure virtual
classes emerged in C++ quite naturally - at that time. But now our focus is
shifting again: as our experience with object-orientation grew and many various
class libraries were created (often with multiple flavors), and the distributed
systems became a reality, we recognized that the notion of interface becomes
crucial and that it is convenient to speak about an interface without an association
of any class with it. So, the interface became a separate design entity and as
such should be present in modern programming language.
  Summary: the "pure virtual classes" was a natural and useful construct in
C++, and it corresponds to the understanding of the matters at the time when
it emerges. But over the past decade the situation changed significantly and
now it seems quite unsuitable to treat an interface as a kind of a class.
  Although I understand the strength of the habits... but it's quite usual and
repetitive story in the programming.


Alexander Kopilovitch                      [log in to unmask]
Saint-Petersburg
Russia

ATOM RSS1 RSS2