Maybe some Lint checker would be useful. I don’t use any for Delphi, but I use for Java and JavaScript. It is great to check all those typo/miss bugs that compiler doesn’t find.
Lars Fosdal Well the main idea is that you can’t access/manipulate the list items except through the interface returned from the Lock() method. The “synchronized access interface” will unlock when it goes out of scope.
So in your case, the code would become:
var
listAccess: IListAccess;
begin
listAccess := ListA.Lock();
listAccess.Add(…); // or whatever you want
end; // list is unlocked when listAccess goes out of scope or is nilled
This way you cannot lock the wrong list (compared to the one you’re manipulating).
So IListAccess would have most of the methods, while IThreadSafeList (or whatever ListA is) would basically just have Lock() and possibly some helper methods if needed.
Guess maybe a generic wrapper could be possible with a bit of voodoo.
Language support is the way here. Heap allocation of an object to implement an interface is overkill. Or you could just get the code right in the first place. I’d take that over darn ref counting.
The power of copy and paste?
I think auto-complete had something to do with this
And this is why you want to protect your mutating methods in a separate interface, which is returned from the Lock() method…
Maybe some Lint checker would be useful. I don’t use any for Delphi, but I use for Java and JavaScript. It is great to check all those typo/miss bugs that compiler doesn’t find.
I have found something for Delphi like codehealer.com – Code Healer Group Home Page Anyone tried it or can recommend some other tools?
Sounds like an entry for FixInsight…
Dorin Duminica I suspect you are right.
Asbjørn Heid How would that look, syntactically?
Lars Fosdal Well the main idea is that you can’t access/manipulate the list items except through the interface returned from the Lock() method. The “synchronized access interface” will unlock when it goes out of scope.
So in your case, the code would become:
var
listAccess: IListAccess;
begin
listAccess := ListA.Lock();
listAccess.Add(…); // or whatever you want
end; // list is unlocked when listAccess goes out of scope or is nilled
This way you cannot lock the wrong list (compared to the one you’re manipulating).
So IListAccess would have most of the methods, while IThreadSafeList (or whatever ListA is) would basically just have Lock() and possibly some helper methods if needed.
Guess maybe a generic wrapper could be possible with a bit of voodoo.
If I could remember that one other language that has something like this using keyword which basically just is syntax for try/finally something…
Stefan Glienke Hehehe
Language support is the way here. Heap allocation of an object to implement an interface is overkill. Or you could just get the code right in the first place. I’d take that over darn ref counting.
Asbjørn Heid this is exactly what one of the clients used in a few projects. Works splendid!
I do this way too often.. 🙁
CriticalSection.Enter;
try
// blah blah
finally
CriticalSection.Free;
end;
oops..