David Heffernan

Your argument about intent is the closest that I have ever seen to a cogent argument on this subject. But I still don't buy it. In your argument, if you see code that sets references to nil then that indicates this "optional lifetime" pattern, for the sake of inventing a name. And your point is that if you set the reference to nil every time you destroy an instance, then you can't distinguish the optional lifetime pattern from the two more common lifetime patterns, let's call them "owned lifetime" where the object is destroyed in its owner's destructor, and "local variable lifetime" where the object is created and destroyed in a local method, and the reference is a local variable. The thing is though, when you see FAN in owned lifetime and local variable lifetime, it's unmistakeable what the lifetime is. You never think, oh, I wonder if this might be optional lifetime. That's why I don't buy the argument, and why I've never experienced the issues you describe. What I have experienced though is the pain of using a stale reference. That pain is eased if the reference is nil. And yes, we can use debug MM to write over memory when an object is destroyed, but I don't want that to happen in my release builds. And sometimes bugs only emerge in release builds.

True. But then I've never made that claim.

My code uses FAN rather than free as a rule, and I don't recognise the problem you describe. That's my practical experience.

Wrong solution. Right solution is to learn what you don't know how to do. No shortcut. Certainly not by just saying "use interfaces".

This makes no sense at all. If you instead use Free and retain a stale reference to a destroyed object, then other code simply cannot know that the reference is stale. There are two main scenarios. Object destroyed by owner, either from another instance's destructor, or in a method with try finally lifetime. FAN is just a debugging guard against use after free. Or a reference to an instance whose lifetime is dynamic. Perhaps created and destroyed multiple times by its owner. Then nil is used to indicate the state that the object is currently not in existence. It seems bizarre to me that anybody could advocate carrying around stale pointers.

As you say, that's a problem with the developer rather than the function itself. I personally use FAN everywhere and my debug builds use FastMM with all bells and whistles. There aren't downsides to using FAN and it does make it easier to catch some defects.

You fix the bug, which is nothing to do with FAN. That's my point.

No it doesn't. How else are you going to allow constructors to raise exceptions?

Yeah, because delphi is so fast! But also, I doubt you could find a real program that would have a measurable performance hit even if the ref was set to nil always.

Amazing that there's anybody left that doesn't know that Free does the nil check itself.

That's a bug to use that reference, so this issue can safely be ignored with regards FAN.

As an aside, even in Delphi there is no such need. You can write 'first line'#13#10'second line' And even then, concatenation of literals is performed by the compiler, so the above code would result in the same codegen as 'first line' + #13#10 + 'second line' Finally, it is usually preferable to use sLineBreak rather than #13#10 so that your code is more expressive, and platform independent.

So instead of code like obj.foo := obj.bar + 10; you prefer obj.setFoo(obj.getBar() + 10); or perhaps obj.setFoo(obj.getBar + 10); (note that I personally am not keen on being able to call a function without the parens because it leads to ambiguity for type inference)

These two statements appear in conflict with each other. Advocacy for using getter/setter methods directly, flies in the face of criticism that properties can't be passed as var or out params. Neither can methods.

Perhaps the data module isn't being destroyed. If you showed a minimal reproduction then we'd be able to tell.