The dreaded with…
Debugging today, I found another gotcha.
In this case, both Self and DisconnectedClient has a property named ClientIdentifier.
Note the difference for the mouse-over and the evaluation.
The dreaded with…
Published
The dreaded with…
Debugging today, I found another gotcha.
In this case, both Self and DisconnectedClient has a property named ClientIdentifier.
Note the difference for the mouse-over and the evaluation.
Nice! 😉
The love for `with`…
This is one reason why my company (and I^^) dont allow the usage of with 😉
With (ahaha^^) great power comes great responsibility
Had they at least gone the route VB did, and require a . to access the “with’ed” members…
with is evil… 🙂
With can be used responsibly, as in:
with AnObj do
Prop1 := MyVal;
Prop2 := SomeValue;
Prop3 := SomeOtherValue;
end;
Where usage becomes evil is when the with clause contains more than a few lines of simple code, or when it specifies multiple objects. In the latter case, it is as difficult and dangerous as multiple inheritance.
Given that it is always an alternative to declare a local variable of the desired type, with a short name, and thereby gain the benefits of with, while encountering none of its ugly aspects, that is generally preferable.
with
r as SomeVar[ix].Reference,
x as SomeOtherRef
do begin
r.prop := x.Value;
…
would have been nice.
Lars Fosdal yes, I’ve seen that being suggested numerous times (;
Lars Fosdal Certainly an improvement, but personally I’d prefer inline variable declaration and references (ala C++).
Asbjørn Heid Well, C++ is certainly available, if you prefer it. 😉
Asbjørn Heid – The type is implied in my suggestion – and you could cast the right side if you needed to. Another point is that this limits the scope to just the with clause.
Bill Meyer True true.