[fpc-devel] "referenced properties" vs "value properties"

[Martin]

On 20/09/2011 13:21, Skybuck Flying wrote:
> The problem with properties currently is that it does not allow partial
> modification of records or arrays, when a property is of type record or
> array it's a everything or nothing situation, either the entire 
> record/array
> is overwritten/returned or nothing at all, this is very inconvenient and
> also bad for performance.

This is not the prolem with properties. This is what "property" means in 
pascal. This is the reason why there is a property at all.

If you don't want that, do not use a property, just use a field 
(member/variable) instead.

you can always do
   TFoo =Class
   public
     Bar: TSomeRecord; // field/variable
   end;

And all will work.

The main reason to use a property
   property Bar: TSomeRecord read Fbar write FBar
is to declare that the implementer reserves the right, to later put 
getter/setter function/procedures in place

It tells the compiler, that while the developer did not yet write any 
such code, the compiler should/must protect "Bar" in a way that any code 
referring to it, will work, if getter/setters are written.

But with a getter, Bar is a function result => so you can not do
   GetBar().xyz := 1

At least not meaningful: because you do not have the original FBar, you 
only have a temporary copy returned by GetBar.
Even if pascal would have functions that return lvalues, GetBar could 
have created a result on the fly. There may not be a FBar variable at all.
   function GetBar: TSomeRecord;
   begin
     Result.xyz := random(5);
   end;
With this function, what you suppose that "Bar.xyz := 1;" should do? 
Since Bar is GetBar, which retturns a record created on the fly, that 
will be dropped straight away

The only way ossible would be for the compiler to translate it into
   tmp := Bar;  tmp.xyz := 1; Bar:=tmp;
which would be the same as
   tmp := GetBar();  tmp.xyz := 1; SetBar(tmp);
And SetBar could have plenty of side effects, that do far more than just 
updating xyz.The original code never said to update the entire "Bar" => 
so it must not be translated to do so.

So again: using the keyword property means =>assume there is no variable 
at all; assume it may be a function, getter/setter ....

If you do not want that, do not use it.

There is no rule, that you must use properties. Making a field public 
accessible is absolutely ok.
Most peopl edo not do it => because, if uou do not have a specific 
reason to do it, then using property means that at absolutely no cost, 
you can reserve the possibility of future extension should you need to. 
Hence, unless you have a good reason not to use property, you should use 
it. But if your design does not allow for it, do not use it.