What is the difference between field declarations at the beginning of a class and those declared in the public section?

They are all visible aren't they, what is the conceptual difference between them?

Frank Church wrote

What is the difference between field declarations at the beginning of a class and those declared in the public section?

There is no "the" public section. You can declare as many public (and private, and ...) sections as you want.

They are all visible aren't they, what is the conceptual difference between them?

None. The default visibility of fields in a class declaration is "public".

Jonas

Unless the class was compiled with {$M+} or is a descendant of such a class, then it is Published.

Michael.

So it means that unless a field or method is in the private or protected section it is automatically public?

Frank Church wrote

So it means that unless a field or method is in the private or protected section

or published, strict private or strict protected section

it is automatically public?

Yes (or published in case of {$m+}, as Michael added).

Jonas

If that is the case then a lot of Free Pascal and Delphi demos are teaching bad practices because they make most members accessible externally when there is no real reason to. I never thought about that much because I just wanted to get my apps working rather than think about proper OOP practices, especially in the case of UI objects like forms, controls etc

If you talk about the fields that are for the controls in a form, than this is intended. TForm, TFrame and TDataModule are descendants of TPersistent which has the {$M} option enabled, thus the default visibility is "published" and then and only then these fields and methods are accessible through RTTI (*). This is e.g. needed if you want to use a file like a DFM/LFM which stores your layout information (the way the GUI in Delphi/Lazarus works).

(*) The extended RTTI of Delphi 2009 and newer allows more options
regarding this.

Regards,
Sven

Correct, but that is what Borland, CodeGear, Embarcadero and Lazarus call "RAD development". I consider RAD just great for prototyping, not for real-world apps that need to be maintaing my many programmers over a decade or two. RAD promotes a lot of bad habbits: bad OOP design by making everything public, mixing business rules in the UI code via easy event handlers in a form etc etc.

The major problems comes in due to the Form Designer in Delphi and Lazarus. The Form Designer solely works due to RTTI, and for RTTI to work you need Published properties - thus publicly visible to all.

This is why the fpGUI's UI Designer doesn't use RTTI. So by default all components I drop on a form are in the Private section of the form class. I then make specific data captured by a form public via public or published properties - I never move components like TEdit or TMemo to a public section in a form class. Like you said, that is terrible OOP design!

Maybe the form designer in the latest Delphi can now be improved because RTTI was recently extended and can now see more than just Published properties. FPC doesn't support this yet.

In our previous episode, Graeme Geldenhuys said:

Strangely, I would have agreed in my previous job. There we had a big monolithical app that was maintained by a team for one big customer.

In my current job every project is a heavily customized variantion on a basic framework, and the requirements and direction of the project are quite often have hard to predict. If you have to write off a higher percentage of the work you do on the current project only, one can be less principal in these things.

The major problems comes in due to the Form Designer in Delphi and Lazarus. The Form Designer solely works due to RTTI, and for RTTI to work you need Published properties - thus publicly visible to all.

Having to publish the form elements is not elegant or perfect, but I understand the reasons and IMHO it is not really a problem.

But IMHO information hiding should just be a first order safeguard, not a micromanaged contract.