The setter expects type complex, hence it is not possible to make an assignment to the real or imaginary part only, e.g.Yes. FPC 3.0.4 - no compiler warnings using (dangerous) with.throws a compiler error "Argument cannot be assigned to".
A[0,0].re := 1;
That is understandable. But when I encapsulate this in a "with" construct, the assignment still does not work, but there is no compiler warning. Rather dangerous, and I suspect a bug. Please confirm.
FPC 3.0.4, win32
The code below defines a 2D Matrix of complex numbers. The elements are stored in linear array "data", and can be accessed via getters/setters.You can report it, but I don't know whether we can get the compiler to error out in that case as well...
The setter expects type complex, hence it is not possible to make an assignment to the real or imaginary part only, e.g.throws a compiler error "Argument cannot be assigned to".
A[0,0].re := 1;
That is understandable. But when I encapsulate this in a "with" construct, the assignment still does not work, but there is no compiler warning. Rather dangerous, and I suspect a bug. Please confirm.
FPC 3.0.4, win32
I don't see anything wrong with it, it's just a miss use and miss understanding of WITH.But it's misleading. SomeVar.SomeRecProp.x := 42 fails already, so it would be logical that with SomeVar.SomeRecProp do x := 42 fails as well. Otherwise this can lead to subtle bugs that are hard to catch as only the temporary variable is modified.
A Getter is a function in the background, so no matter what you'll never be able to modify the source of the Record only the given from the local heap.
Using WITH in this manner is exactly what it is designed to do, why should you expect compiler warnings or errors? The WITH has open the name space to that of the RECORD so now all members of that RECORD returned is available and of course in this case it's working with the currently local Heap version of it.
I think a WARNING would be sufficient but it would need to be specific to this case.FPC is not automatically calling the setter anyway. Where do you get that from? FPC actively forbids changing the value of a record's field that has been returned by a property. Same should be true if the result is used in a with as that will result in consistent behavior.
In all fairness I don't think you'd want the Setter to be called each time you set a member because the setter may assume all fields are set and then process it as though. So with two members for example, the setter may do something twice, first with incomplete data and the next
time completed data.
SomeProperty := With SomeOtherProperty do begin // make all the changes here to the property body given. // do other unrelated things. End;
A compiler enhancement which I am sure does not work in Delphi could really move FPC to the present...No. That is anything, but good language design.That would allow a visible entity to be assigned to a sub entity when the block completes.
SomeProperty := With SomeOtherProperty do begin // make all the changes here to the property body given. // do other unrelated things. End;
Now that would move FPC to the space age! :)
IMHO, a function works just as well and is more readable:You can not use a var-parameter with a property.
function DoSomethingWith(var AProperty: TWhateverType): TSomeOtherType; begin with AProperty do begin // make all the changes here to the property body given. // do other unrelated things. end; end; {... lots of other code ...} SomeProperty := DoSomethingWith(SomeOtherProperty);
It'll also isolate in the function's body any side-effects the block of code has, which is nice for debugging.