What do you thing of this idea I'm using more and more in my code ?
What do you thing of this idea I'm using more and more in my code ?
instead of writing
if (MyObject <> nil) and (MyObject.Locked) then
Exit;
I write
if MyObject.Locked then
Exit;
with
function TMyObject.Locked: Boolean;
begin
Result := (Self <> nil) and FLocked;
end;
it can also be
function TMyList.Count: Integer;
begin
if Self = nil then
Exit(0);
...
end:
function TMyList.GetItme(Index: Integer): TMyObject;
begin
if Self = nil then
Exit(nil);
...
end;
instead of writing
if (MyObject <> nil) and (MyObject.Locked) then
Exit;
I write
if MyObject.Locked then
Exit;
with
function TMyObject.Locked: Boolean;
begin
Result := (Self <> nil) and FLocked;
end;
it can also be
function TMyList.Count: Integer;
begin
if Self = nil then
Exit(0);
...
end:
function TMyList.GetItme(Index: Integer): TMyObject;
begin
if Self = nil then
Exit(nil);
...
end;
Your approach has the advantage that it can also work safely when "Complete Boolean Evaluation" is switched on in the Compiler options. For this you either have to tweak the Locked implementation to allow for this scenario or explicitly switch that off inside that said implementation.
ReplyDeleteIt depends if nil is an OK condition. The alternative is to fail fast hard.
ReplyDeleteJeroen Wiert Pluimers well I it can be an active item on a form or the item under the mouse, so something that can be nil ... and sometime I forget to test if the item exists, so puting the test inside the methods avoid a null pointer exception
ReplyDelete"Complete Boolean Evaluation" must always be OFF. Otherwise all of our codebase fails miserably :) :) :)
ReplyDeleteOTOH, such shorthands are nice if they don't confuse the programmer that will have to read the code after three years. (Which may as well be the guy/gal who wrote the code.)
Are sure the next programmer (or yourself in 3 years) will know that calling these methods is safe?
ReplyDeleteThomas Mueller probably not, but then nil will be tested twice without adding a bug :)
ReplyDeleteThis is the same technique used by the Free method.
ReplyDeleteAny chance of undefined behavior? Is it documented somewhere, that calling method of nil pointer is allowed?
ReplyDeleteVirgo Pärna like Christen sayed, Free is such a method :)
ReplyDeletePaul TOTH I know:)
ReplyDeleteBut maybe it is just special case. It just reminds me those optimizations removing undefined code type of problems in C or C++. Current Delphi compilers are allowing it anyway.
Virgo Pärna, just take care of not using it with virtual or dynamic methods.
ReplyDeleteif MyObject?.IsLocked = True then
ReplyDelete... oh wait, we don't have that (yet) ;)
if xxx = True then, Stefan Glienke ??????
ReplyDeleteStefan Glienke oh yes, we could also have
ReplyDeletelock = (MyObject?IsLocked ? LOCKED : UNLOCKED)
or still use some Pascal afterall
I think it is a very bad idea and I truly hope that other Delphi devs don't start using this in their own code. TObject.Free() is a special case it is valuable and - believe me - lots of devs don't really know how it works internally. Now imagine a huge code base where you have to check each individual method to find out if "this works like Free or works the other way around"? A nightmare.
ReplyDeleteMethod name should be AssignedAndLocked to avoid confusion.
ReplyDelete