Effect of adding properties before the visibility sections?

[vfclists]

I recently got to learn that placing a property before any of the visibility sections in a class definition made it a published property automatically, and it tested out OK.

Code: Pascal  [Select][+][-]

1.   TMyComponent = class(TComponent)
2.     FSomeUnPublishedValue: integer;
3.     property AnInteger: integer read FAnInteger write SetAnInteger;
4.     property WideStr: widestring read FWideStr write FWideStr;
5.     property Grid: TDBGrid read FDataGrid write FDataGrid;
6.     property Panel: TPanel read FPanel write FPanel;
7.   private
8.     FAnInteger: integer;
9.     FWideStr: widestring;
10.     FUnicodeStr: unicodestring;
11.     FAnsiStr: ansistring;
12.     FDataGrid: TDBGrid;
13.     FPanel: TPanel;
14.     FEdit: TEdit;
15.     FControl: TComponent;
16.     procedure SetAnInteger(const AValue: integer);
17.   public
18.   published
19.     property UnicodeStr: unicodestring read FUnicodeStr write FUnicodeStr;
20.     property AnsiStr: ansistring read FAnsiStr write FAnsiStr;
21.     property Edit: TEdit read FEdit write FEdit;
22.     property AControl: TComponent read FControl write FControl;
23.   end;

This leads me to two questions.

1. Does this mean all values before the visibility fields are accessible to FreePascal in other units as are all public and published fields, but only published properties and the properties before the visibility sections will be available to RTTI, ie obtainable from using the methods in TypInfo?

2. When the compile lays out the memory arrangement of the fields, will the properties before the visibility sections be treated as though they were declared in the published sections?

[TRon]

I recently got to learn that placing a property before any of the visibility sections in a class definition made it a published property automatically, and it tested out OK.

No visibility specifier declared means section public see reference manual:

For objects, three visibility specifiers exist: private, protected and public. If a visibility specifier is not specified, public is assumed.

icw published in class definition here:

From a language perspective, this is the same as a Public section, but the compiler generates also type information that is needed for automatic streaming of these classes if the compiler is in the {$M+} state. Fields defined in a published section must be of class type. Array properties cannot be in a published section.

That should be able to answer at least some of your questions.

[MarkMLl]

While not specifically addressing your questions, I'd add that two or three months ago I was looking at something related in the case of class variables ("fields") and found I had to do something like this:

Code: Pascal  [Select][+][-]

1.   TBlip= class
2.     class var InfieldDegs: TVertexDegs; (* Used for range calculation           *)
3.     class var RadioDegs: TVertexDegs;   (* Used for slant calculation           *)
4.     class var RadioAlt: integer;        (* Used for slant calculation           *)
5.   public                                (* This is needed to close var section  *)
6.     Timestamp: TDateTime;
7.     ReceiveTime: Double;
8. ...
9.  

So in effect that confirms that lines before a visibility specifier are public, but it turned out to be necessary to have an explicit "public"  before ordinary fields could be defined.

https://forum.lazarus.freepascal.org/index.php/topic,67667.msg521441.html#msg521441

MarkMLl

[cdbc]

Hi
IIRC by convention the fields and methods in the section between 'class' & visibility specifiers are 'published'.
And AFAICT it's this feature, e.g.: Castle GE exploits in its framework wrt. auto-creation of objects... I think via streaming...?!?
It would naturally depend on {$M+}
Regards Benny

[TRon]

IIRC by convention the fields and methods in the section between 'class' & visibility specifiers are 'published'.

According to the reference manual they are public therefor they are public 

[cdbc]

Hi
In fpc 3.2.2 & Laz 3.6
Paste this into a completely fresh unit1.pas:

Code: Pascal  [Select][+][-]

1. unit unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs;
9.  
10. type
11. {$M+}
12.  
13.   { TVisiTest }
14.  
15.   TVisiTest = class
16.     property UnSpec: ptrint read fUnSpec write fUnSpec;
17.   private
18.  
19.   public
20.  
21.   end;
22.  
23. {$M-}
24.   TForm1 = class(TForm)
25.   private
26.  
27.   public
28.  
29.   end;
30.  
31. var
32.   Form1: TForm1;
33.  
34. implementation
35.  
36. {$R *.lfm}
37.  
38. end.
39.  

Place your caret in this line:

Code: Pascal  [Select][+][-]

1. property UnSpec: ptrint read fUnSpec write fUnSpec;

and press Ctrl+Shift + C to see what happens... It's just a quick test.
Regards Benny

eta: Everything that descends from 'TPersistent' is compiled with {$M+} i.e.: every component!

[TRon]

I see what you meant there cdbc.

However, I don't trust code-tools to have any influence on the matter other then doing its own thing (it usually does).

E.g. how can you be sure that code-tools simply doesn't 'interpret' the shortcut as being "oh, we are in lazarus, we must publish and not restrict ourselves to a public section"). I honestly don't know.

[cdbc]

Hi TRon
I faintly recall in my Delphi days, I was told by some TeamB member, that it was like that by convention and according to my experience, it holds true...
Regards Benny

[TRon]

fwiw: that code-tools decides to publish properties by default I can sort of grasp (annoying as hell but that as an aside) but for code-tools and methods it is actually configurable.

Well, if you are right then the (official) documentation must be wrong so in that case we're doomed 

[vfclists]

Hi
IIRC by convention the fields and methods in the section between 'class' & visibility specifiers are 'published'.
And AFAICT it's this feature, e.g.: Castle GE exploits in its framework wrt. auto-creation of objects... I think via streaming...?!?
It would naturally depend on {$M+}
Regards Benny

Does a field need to be declared as property and be in the published section area or before the visibilty specifiers before it can streamed, in short can a field be streamed without being labelled as a property?

[cdbc]

Hi

Does a field need to be declared as property and be in the published section area or before the visibilty specifiers before it can streamed, in short can a field be streamed without being labelled as a property?

Take one look at a TFormSomething of yours with some meat on the bones...
It streams just fine doesn't it?!? Every TEdit, TLabel or TMemo is a field.
Regards Benny

[PascalDragon]

1. Does this mean all values before the visibility fields are accessible to FreePascal in other units as are all public and published fields, but only published properties and the properties before the visibility sections will be available to RTTI, ie obtainable from using the methods in TypInfo?

No, any property in a published-section (be it the implicit default section or an explicit one) will be available through RTTI. It's just how Delphi does things and Lazarus followed suit. It could just as well declare a separate published-section.

2. When the compile lays out the memory arrangement of the fields, will the properties before the visibility sections be treated as though they were declared in the published sections?

The order of fields is an implementation detail and with optimization -O4 this order might even change if the compiler can make the class definition smaller.

I recently got to learn that placing a property before any of the visibility sections in a class definition made it a published property automatically, and it tested out OK.

No visibility specifier declared means section public see reference manual:

For objects, three visibility specifiers exist: private, protected and public. If a visibility specifier is not specified, public is assumed.

The documentation is not entirely accurate here. The default visibility section of a class is public, however if the class is compiled with $M+ or descends from one that has that enabled it then the default section is instead published.

Hi
IIRC by convention the fields and methods in the section between 'class' & visibility specifiers are 'published'.
And AFAICT it's this feature, e.g.: Castle GE exploits in its framework wrt. auto-creation of objects... I think via streaming...?!?
It would naturally depend on {$M+}
Regards Benny

Does a field need to be declared as property and be in the published section area or before the visibilty specifiers before it can streamed, in short can a field be streamed without being labelled as a property?

Only if the field is a class that has $M enabled or descends from one that has (e.g. TPersistent).

[TRon]

Thank you @PascalDragon for the correction and additional information/explanation about how that works in practice.

👍

[Remy Lebeau]

The documentation is not entirely accurate here. The default visibility section of a class is public, however if the class is compiled with $M+ or descends from one that has that enabled it then the default section is instead published.

This matches with Delphi:

Classes and Objects : Visibility of Class Members

If a member's declaration appears without its own visibility specifier, the member has the same visibility as the one that precedes it. Members at the beginning of a class declaration that do not have a specified visibility are by default published, provided the class is compiled in the {$M+} state or is derived from a class compiled in the {$M+} state; otherwise, such members are public.

[PascalDragon]

The documentation is not entirely accurate here. The default visibility section of a class is public, however if the class is compiled with $M+ or descends from one that has that enabled it then the default section is instead published.

This matches with Delphi:

Classes and Objects : Visibility of Class Members

That's why it's implemented like that in FPC. 😅