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: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)
Subject: Re: Choice of OO primitives in Ada95
Date: 1996/02/19
Message-ID: <4g8vkp$37o@goanna.cs.rmit.EDU.AU>#1/1
X-Deja-AN: 139997464
references: <4fmrhk$7k3@erinews.ericsson.se>
organization: Comp Sci, RMIT, Melbourne, Australia
newsgroups: comp.lang.ada
Date: 1996-02-19T00:00:00+00:00
List-Id: <comp.lang.ada>

ehsjony@ehs.ericsson.se (Jonas Nygren) writes:
>A possible syntax could be outlined as:

>	class type Class_Name [extends Super] is ...
>	
>then we would not have the difficult to master freezing rules
>and controlling operand rules.

I for one am very happy with the Ada 95 model.
It really says a lot for the Ada 83 design that OOP could be grafted
in so cleanly.

The freezing rules are pretty intuitive (note that C also has rules about
when a type must be completed).

>One would simply prefix with
>the 'controlling operand' as for task and protected types.

This is not a simplification.  It is a complexification, because it
forces every operation to have only one controlling operand.  Set
operations are the classic example when you have two operands of the
same type (union, and so on).

Dynamic dispatching is still a form of procedure call; why impose new
syntax when we already have comprehensible syntax that works fine?

Having used Pop-2, where
	f(x)
	x.f
	x, f()
	x, f.apply
and so on all did the same thing, I can no longer get too enthusiastic
about minor differences in syntax.  See a recent discussion in
comp.lang.dylan (which allows both dotted and dotless method calls)
for why dotless might be preferred.

-- 
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.