[fpc-pascal]self

Ingmar Tulva juss_it at ut.ee
Wed Oct 23 14:05:18 CEST 2002


On Wed, 23 Oct 2002, Jonas Maebe wrote:

}I don't think the above will even compile, because var parameters must
}match exactly.

Huh? Not in case of objects! The type of the actual parameter must be the
same as or descendant of the type of the formal parameter, as I recall.
Just like with pointers to objects. And if I'm right, then..

}You can replace the values of all the fields of an object with those of
}another object inside a method (this is important, because when you're
}outside a method, you can simply assign one object to another) without
}having to type all the fields explicitely.

...you cannot replace them all, because the program flow can fall on
t1.p() without any clue about what new kinds of descendants of t1 could be
Self or the actual parameter. When dealing with objects or classes, you
never really know it. So it seems, all that can be done is to assign
the fields declared in t1.
Then again, if t1.p() cannot handle additional fields of decendants, then
all its descendants inherit a method which can, for some reason, replace a
part of the object with corresponding part of another object?

Well, it's very much a matter of aesthetics. Maybe it's just me but I feel
that if Self:=Something were allowed, it should properly handle all
possible descendant types of both Self and Something - but that is
impossible to accomplish.

One more example:

type
  t1 = object
    procedure p ({var/const/whatever} s:t1);
  end;
  t2 = object(t1);
  end;
  t3 = object(t1)
  end;

procedure t1.p (s:t1);
 begin
   Self:=s;
 end;

var
  o1 : t1;
  o2 : t2;
  o3 : t3;

begin
  ---
  o2.p(o3);
  ---
end.

What type o2 now belongs to? If Self:=... is equivalent to assignment
of records, then VMT pointer was assigned, too, and o2 has VMT of type t3
(which leads to question, what happens when o1:=o3? Honest, I don't know).
Or, if you have taken care of this and don't assign VMT pointer together
with fields, imagine that t1 containes a field which is to be interpreted
differently by t2 and t3 - like, for example, TCluster.Value of Turbo
Vision? Also, note that we couldn't do o2:=o3 in the above example -
compiler would give type mismatch, and for good, I think.

Just to keep discussion alive,
Ingmar Tulva





More information about the fpc-pascal mailing list