Make "private" members behave like "strict private"

Question

What about a feature in an upcoming Delphi version enabling that?

Maybe it could be a compiler switch promoting all privates to strict privates.

... or it could be a feature of the new non-legacy compiler font-end Nick Hodges was talking about. => private does always behave like strict private.

EDIT: The reason why I want this is because I just don't want to add thousands of stricts to my private modifiers. Furthermore the "strict private" behavior is the default behavior in any object oriented language I'm familiar with!

Answer 1

To quote from the article:

So, we are working to create a “new Delphi” and a new compiler architecture, to keep your existing code working, to emit 64-bit binaries using both Delphi and C++Builder, and maybe a few other kind of binaries while we are at it. And it all has to be done right so that it all works for you.

I interpret that as, if codegear is going to change the behaviour of private. Then they wil proide an option to keep the old behaviour just like they did in the past.

Just for clarification, within a class there are 6 different access levels (ok 7 but automated is deprecated).

public: Anything that can access the object can access this.
protected: Methods in the class and its subclasses and anything in the same unit can access.
strict protected: Methods in the class and its subclasses can access.
private: Methods in the class and anything in the same unit can access.
strict private: Methods in the class.
published: As public buth with runtime information for the object inspector.

Answer 2

I don't quite understand the question. But why would you need this feature? Why not just replace Privates in your code with Strict Privates if that is what you desire?

Answer 3

The current private implementation is private to everything outside the unit it is declared in. So if your reasoning for not wanting to add the strict statements is that you don't want to modify your existing units, then you have nothing to gain except breaking any existing code that accesses the class in the same unit. As long as your existing units are not modified, then the difference between strict and non-strict private is academic.

If your reasoning for the strict behavior is to use the compiler to help you refactor code that takes advantage of the less-private behavior, then adding the strict to one class at a time is a good incremental approach so you can get to a compilable and testable state more often. A whole sale change of behavior would require fixing every violation before you knew if any of them worked.

The reason private behaves like it does is similar to C++'s friend - it allows certain classes (or procedural code) to access private members. The VCL and RTL makes heavy use of this behavior, so a compiler switch or an all out change would break all of that code.

Delphi's implementation of private is private enough for all practical purposes since typically you control the unit your class is declared in. If you only ever declare one class per unit, and never include procedural code, then the difference is only academic.

Answer 4

I expected your reason for wanting to change the meaning of private was that you wanted the stricter behavior without having to break backward compatibility. I figured you were producing a library that you wished to be usable with Delphi 7 and prior, which don't have the strict modifier.

But if that's not your reason, then I don't think you've got much to work with. You can convert all your private code to strict private pretty easily with a simple script.

perl -i.bak -pe 's/(?<!\bstrict )\b(private|protected)\b/strict $1/ig' *.pas

That takes any private or protected that isn't already strict and puts strict in front of it. It modifies the files in-place. (Beware; it may insert "strict" into string literals, too.)

So anyway, I don't think we're going to see private become strict anytime soon. Doing that could break old code, and there's not really much practical gain from it. It lets purists have "more pure" code, but they can already have that simply by using strict. I think that if we were ever going to have "default strict" visibility, then the time for the change was when strict was introduced in the first place. But as things are today, we already have a way of getting strict visibility specifiers, so there's no need for another change.