Is there a trick to make (in mode macpas) all class methods implicitely virtual ? I mean, without adding the virtual keyword to all of them ? The reason is that I want to create a tree view of the class hierarchy with all the method names (not just those that are normally in the VMT because they are overridden).

Any other ideas ?

Regards,

Adriaan van Os

Is there a trick to make (in mode macpas) all class methods implicitely virtual ? I mean, without adding the virtual keyword to all of them ? The reason is that I want to create a tree view of the class hierarchy with all the method names (not just those that are normally in the VMT because they are overridden).

Hm, looking somewhat further, it seems that the vMethodTable of the class VMT does list all methods, not just the virtual methods, provided the code was compiled with type info {$M+}

is that correct ?

Regards,

Adriaan van Os

Adriaan van Os via fpc-pascal schrieb am
Mo., 9. Okt. 2023, 14:29:

No, there is no such way.

Regards,
Sven

Adriaan van Os via fpc-pascal schrieb am
Mo., 9. Okt. 2023, 15:44:

No. Only those in the published section are part of the vMethodTable. And when compiled with $M+ the default visibility is changed from public to published.

Regards,
Sven

Sven Barth wrote

No. Only those in the published section are part of the vMethodTable. And when compiled with $M+ the default visibility is changed from public to published.

OK, but that means that by explicitely specifying public/private/protected for fields and published for methods, a method list can be generated when compiling with {$M+}.

Regards,

Adriaan van Os

If you need this tree at run-time:

- The "extended RTTI" branch of fpc allows you to list all methods, regardless of their visibility

- In the released compiler, if you remove all visibility specifiers, you can get a list by specifying {$M+} on your base object and then list all published methods using the RTTI.

If you simply need this tree:

- You can simply use fcl-passrc to analyse your source tree and create the complete list. No changes to code needed. I have several programs that do this.

Michael.

Sven Barth wrote

No. Only those in the published section are part of the vMethodTable. And when compiled with $M+ the default visibility is changed from public to published.

Also, I can get a list of the interfaces inherited from by a class, by looking at the vIntfTable of the VMT of the class. But is there also a way to get the method names from a CORBA interface ?

Regards,

Adriaan van Os

Interesting ! If I am correct, the docs referred to at <https://gitlab.com/freepascal.org/fpc/source/-/issues/38964> say

; visibility-clause:
; METHODS|PROPERTIES|FIELDS (visibility-expression)

Does that mean that the "extended RTTI" branch supports RTTI for fields ?

My understanding is that I have to explicitely specify public for class fields, otherwise the compiler will issue an error.

Will try that out, thanks.

Regards,

Adriaan van Os

Yes, it should be compatible with Delphi so all fields with the specified visibility will be , Ryan Joseph

Regards,

Adriaan van Os

Only for the class that is parsed while $M is enabled and all that inherit from that class. It does not affect any parent classes that don't have $M enabled.

Regards,
Sven

CORBA or raw interfaces don't have RTTI generation enabled. And even then the (COM) interfaces also need to have been parsed with $M enabled.

Regards,
Sven

What exactly do you mean here? Do you have an example?

Regards,
Sven

{$mode macpas}
{$M+}
program testrtti;
type
   T = object( TObject)
     i: integer;
     procedure A;
   end;
procedure T.A;
   begin end;
begin
end.

Free Pascal Compiler version 3.0.4 [2018/09/30] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Darwin for x86_64
Compiling testrtti.pas
testrtti.pas(6,5) Error: Symbol cannot be published, can be only a class testrtti.pas(13) Fatal: There were 1 errors compiling module, stopping

Regards,

Adriaan van Os

Adriaan van Os via fpc-pascal schrieb am
Mi., 11. Okt. 2023, 06:25:

Ah, yes, only classes and interfaces can be used for published fields. For properties anything is allowed.

Regards,
Sven

Sven Barth wrote

Ah, yes, only classes and interfaces can be used for published fields. For properties anything is allowed.

However, what makes the whole thing unuseable is that with {$M-} the compiler doesn't accept "published". So, without using macros, the same source code can not be compiled with both {$M+} and {$M-}. That is really clumsy. With {$M-} "published" (or some other visibility specifier) should be equal to "public".

Regards,

Adriaan van Os

Of course not.

$M controls the inclusion of RTTI, i.e. it allows or disallows the use of the published section. No more, no less.

It has no impact on the other visibilities whatsoever. And that will not change, if only for Delphi compatibility.

If this is not acceptable, then you will need to wait for the extended RTTI or use fcl-passrc to solve your need.

Michael.

Michael Van Canneyt wrote

$M controls the inclusion of RTTI, i.e. it allows or disallows the use of the published section. No more, no less.

I don't see any use in allowing or disallowing something. And with the current design, it is, as I said, impossible, without macros, to compile the same code with {$M+} and {$M-}.

It has no impact on the other visibilities whatsoever. And that will not change, if only for Delphi compatibility.

Adding a visibility specifier "visible" meaning "published" with {$M+} and "public" with {$M-} doesn't degrade Delphi compatibility. Anyway, I did that now for my source code with macros, but it's clumsy.

If this is not acceptable, then you will need to wait for the extended RTTI or use fcl-passrc to solve your need.

I tried fcl-passrc but it didn't produce anything but crashes. I much welcome the extended RTTI.

Keep up the good work.

Regards,

Adriaan van Os

While I agree with your statement about allowing/disallowing use of 'published' based on a directive, we inherited this from Delphi and it is a very basic part of the language & RTL, so changing it is simply not an option.

The extended RTTI is meant to remedy this (also in Delphi), but IMO it introduces its own problems (you'll love the amount of compiler directives it needs ;)).

I'm surprised to hear about your failure to get fcl-passrc to work, since it is used to create the docs based on the fpc sources. Additionally it forms the basis of pas2js, which fully supports all FPC constructs.

That said, I realize the (correct) use of fcl-passrc may be a bit hermetic...

Michael.

Adriaan van Os wrote

I don't see any use in allowing or disallowing something. And with the current design, it is, as I said, impossible, without macros, to compile the same code with {$M+} and {$M-}.

Use $IfOpt instead of macros?

{$IfOpt M+} published {$Else} public {$EndIf}

I have a generic include file that has

{$ifc not defined HaveTypeInfo}
{$M-}
{$definec visible public}
{$elsec}
{$ifc HaveTypeInfo}
{$M+}
{$definec visible published}
{$elsec}
{$M-}
{$definec visible public}
{$endc}
{$endc}

and now I can use "visible" as a new visibility specifier, which is more elegant and easy-to-read (and less typing) than polluting the code with lots of

	{$IfOpt M+} published {$Else} public {$EndIf}

Regards,

Adriaan van Os

Well, as I said, adding a new visibility specifier, e.g. "visible", meaning "public" in {$M-} state and "published" in {$M=}", does in no way degrade compatibility with Delphi code. One could reserve the new visibility specifier for modes objfpc and macpas.

Regards,

Adriaan van Os

Adriaan van Os via fpc-pascal schrieb am
Fr., 13. Okt. 2023, 11:02:

There will be no new visibility specifiers for something like this.

And yes, it affects compatibility, as that means that code using that feature couldn't be compiled with Delphi and especially for library developers that might be an important point.

Regards,
Sven

That's absurd, there are many features in modes objfpc and macpas that don't compile with Delphi.

Regards,

Adriaan van Os

Adriaan van Os via fpc-pascal schrieb am
So., 15. Okt. 2023, 08:54:

That doesn't make it any less true.

Also we won't add it anyway, so... 🤷‍♀️

Regards,
Sven

Apperently, a sensible discussion, based on logical arguments, instead of dogma, is impossible.

Adriaan van Os

This has nothing to do with dogma.

You ask to change the language. A considerable change by any standards, requiring persuasive arguments, and your arguments for this change are simply not persuading enough.

Changing the language so you can get your list of methods is an ad-hoc solution to a (from our point of view) non-problem.

There are (or will be) other solutions to your particular problem, making such a change simply unnecessary.

We can argue about the manner in which Sven closed the discussion, but that's a matter of style, not dogma.

Michael.

Adriaan van Os via fpc-pascal schrieb am
Mo., 16. Okt. 2023, 15:14:

To quote our FAQ at https://www.freepascal.org/faq.html with the entry "There is a new language extension that would be really useful. Will you include it?" at point 2:

"The extension must have real value. Anything that is only a shorter notation does not apply, unless it is out of compatibility with an existing Pascal/Delphi codebase. Practically it means it must make something possible that cannot be done otherwise or be a compatibility item"

Your suggestion fails that as it is merely syntactic sugar for something you can accomplish using existing mechanisms even if it might be more involved.

Regards,
Sven