Hi,

I ported some code (a Relationship Manager design pattern) that was written in Delphi to Free Pascal. I noticed that the original author used 'strict private' in the class declarations - where one unit had multiple classes.

I simply removed the 'strict' part and FPC was happy. Is FPC going to support the 'strict private' keywords?

I haven't read up on what exactly it means, but from the name, I would guess that if you have multiple classes in a single unit and some code is under 'strict private' section, that the other classes can't access it? By default in FPC all code, even from different classes, in the same unit can access anything in other classes (private, protected and public). Is my assumption correct? If so, this could be a handy addition.

To achieve the same in Free Pascal, those classes will have to be defined in separate units, which is not always ideal.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I'am quiet sure FPC supports strict private in delphi mode.

Florian Klaempfl wrote

I'am quiet sure FPC supports strict private in delphi mode.

Oh, I never tried that. I 99.99% of the time use ObjFPC mode - I much prefer the more strict language rules. Why doesn't FPC support 'strict private' in ObjFPC mode as well? It seem like a very handy feature that many developers could benefit from, not just in Delphi code ported to FPC. Just in my code alone, I can think of a few places where it could be used.

Plus it's a non-invasive feature. If you don't know about it, or simply don't use it, your code acts exactly the same as it did before.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Code like
type to1 = class

       strict : longint;
     end;

breaks iirc.

In our previous episode, Graeme Geldenhuys said:

IMHO strict private has nothing to do with strictness, except for the first word. It has to do with micromanaging visibility, something I do not agree with, not in the least because the exact use is highly a matter of taste.

I would prefer to keep it far from FPC codebases.

Do you mean you agree with the design flaw in the original object pascal specification from Borland? Plz explain...
IIRC even Anders admitted that simply separating interface from implementation was based on only partial knowledge of the OO paradime and has corrected that oversight in C#.
IMHO "strict" is a good thing and by design, albeit not implemented soon enough in history. Unlimited visibility in the implementation section makes for unreliable programming and therefore should be considered a bug if not a potential lethal and stealthy source for those insects.

In our previous episode, Thaddy said:

First, I'm not sure it is a bug/flaw. Second, I'm sure I don't want more visibility levels.

IIRC even Anders admitted that simply separating interface from implementation was based on only partial knowledge of the OO paradime and has corrected that oversight in C#.

Is that the same Anders that allowed umpteen directives, modifiers etc in C#? No wonder he has no problem with it :-)

IMHO "strict" is a good thing and by design, albeit not implemented soon enough in history

Well, a case could have been made then, but IMHO changing it is no option out of compatibility, and adding another level is IMHO worse then the actual problem.

Unlimited visibility in the implementation section makes for unreliable programming and therefore should be considered a bug if not a potential lethal and stealthy source for those insects.

IMHO that is an opinion, not a fact. I could counter that more levels in visibility lead to more errors in visibility.

However my consideration originate more from the discussions about other post D7 modifiers that try to micromanage visibility. My own end conclusion were that while they give the feeling of control and safety, they don't really add to security, specially because a perfect visibility can only be decided in retrospect, when all applications are known.