> I have the following declarations
>
> TYPE
> T* = ARRAY 16 OF CHAR;
> List* = POINTER TO ListDesc;
> ListDesc = RECORD
> value: T;
> link: List
> END;
>
> and wish to implement the following methods (among others)
>
> PROCEDURE (VAR ls: List) ClearList*, NEW;
> BEGIN
> ls := NIL
> END ClearList;
>
> PROCEDURE (VAR ls: List) InsertBefore* (n: INTEGER; IN v: T),
> BEGIN
> ...
> END InsertBefore;
>
> PROCEDURE (VAR ls: List) RemoveNth* (n: INTEGER), NEW;
> BEGIN
> ...
> END RemoveNth;
>
> Each of these requires that the pointer in the receiver (possibly)
> be changed, but the language does not permit VAR with the pointer
> in the receiver. (1) Why does CP have the restriction,
If you use your above definitions in a client program as follows, things start
getting confusing (in my view):
PROCEDURE DoSomethingWithList (VAR l: List);
VAR l1: List;
BEGIN
l1 := l;
(* l1 and l refer to the same list *)
l1.InsertBefore(5, ...);
(* l1 and l still refer to the same list *)
l1.InsertBefore(0, ...);
(* l1 and l no more refer to the same list *)
....
On the conceptual level:
A receiver being a variable parameter of pointer type means that an object may
be replaced by another one as the side effect of sending a message to it. This
would be foreign to traditional object-oriented programming and could lead to
confusing situations.
(As Stephan already mentioned, CP inherited this definition from Oberon-2.)
> and (2) how
> can I do this without resorting to proper procedures, where VAR with
> a pointer is allowed? My problem is to introduce linked lists to
> beginning programming students using methods, and I would rather not
> mix procedures and methods (and definitely not polymorphism at this
> point).
Being concerned with teaching myself, I would like to suggest another point of
view. When teaching a technical concept -such as methods-, you also need to
teach what it is good for and when it shall be used, i.e., under which
circumstances the overhead pays off. The only reason, I know of, to use
methods or type-bound procedures is some sort of polymorphism. Hence, if you
are not introducing polymorphism at this point, how do you intend to motivate
to use type-bound procedures in the first place? Wouldn't plain procedures be
the right thing to use?
As a side note: historically, type-bound procedures in Oberon emerged as a
refinement of "object-bound procedures", that is, procedure variables in
records. These in turn became necessary because of the need for polymorphism.
One could try to use the same path in teaching: show what polymorpism is good
for and then discuss how a programming language can support it.
Well, just my 0.02 Euros, of course :-)
Wolfgang
-------------------------------------------------------------------
Dr. Wolfgang Weck
Turku Centre for Computer Science
Åbo Akademi University, Department of Computer Science
Lemminkäisenkatu 14A, FIN-20520 Turku, Finland
Phone: +358-2-215 4673, Fax: +358-2-215 4732
mailto:Wolfgang.Weck@abo.fi, http://www.abo.fi/~Wolfgang.Weck/
-------------------------------------------------------------------