[Lazarus] Passing properties as var paramatars (was: Delphi editor clone)

[Alexander Klenin]

On Sat, Nov 7, 2009 at 14:15, Martin <lazarus at mfriebe.de> wrote:

> The answer was that properties are meant to change the value on the object
> immediately. Also a property setter can raise an exception, or additional
> actions can take place or the value can be substituted....
> All this wouldn't happen with a temp variable (or at best deferred).
> Therefore the behaviour would not be according to the rules of properties

I thought about that too. There are few counter-arguments here:

Strictly speaking, properties are not *meant* to change anything
neither immediately nor
in any other way. Assigning to a property with the setter is just a
procedure call,
and I do not think there exist any specification requiring the setter
to change anything.

So it is important to understand that we are dealing here with "common
sense" and "usual expectations",
not with any formal requirement.

Now the question is, given the code:
-----
type T = class
  ...
  property P: Integer read GetP write SetP;
end;

procedure MyInc2(var a: Integer); begin a := a + 1; a := a + 1; end;

var obj: T;
begin
  MyInc2(obj.P);
end.
-----

what is the *usual expectation* of the number of calls to GetP and SetP?
Using temporary variables, there will be one call to each.
It might be argued that some programmer might expect two calls to each,
but I am really not sure if such programmer exists ;-)
Moreover, if we assume the existence of such a hypothetical programmer,
how could he implement MyInc2 to achieve the behaviour he expects?
The answer is: he could not. It is impossible with or without the
proposed extension.

So we must conclude that the possible downside is relatively small.
It must be weighted against the upside:

Components[ComponentIndex].Options :=
Components[ComponentIndex].Options + [myOption];

vs

Include(Components[ComponentIndex].Options, myOption);

is, IMO, a very compelling argument.

-- 
Alexander S. Klenin