Hi list,

I've run makeskel on ibconnection.pp.

This declaration:
  protected
...
    function GetHandle : pointer; override;

gets output as:
<!-- function Visibility: protected -->
<element name="TIBConnection.GetHandle">
<short></short>
<descr>
</descr>
<errors>
</errors>
<seealso>
</seealso>
</element>

<!-- function result Visibility: default -->
<element name="TIBConnection.GetHandle.Result">
<short></short>
</element>

Shouldn't the TIBConnection.GetHandle.Result function result visibility be protected as well?
I understand that the function result is... let's say "default" with respect to the fact that if you can call the protected function you get the result as well, but it might make it easier for people like me (and perhaps tools) to ignore these when writing documentation for end users...

Thanks,
Reinier

Reinier Olislagers wrote

Shouldn't the TIBConnection.GetHandle.Result function result visibility be protected as well?

I have no idea what "default" visibility actually means. I can add that parameters and function results don't generate any visibility headers in the documentation output. So from a documentation point of view you can ignore that. But I would be curious to know from Michael (or somebody else) what default visibility means?

On a side note:
For the FPC documentation, only Public and Published methods & properties are documented. So you should have generated the initial xml file specifying only Public or higher visibility in the output makeskel generates.

Regards,
- Graeme -

So apparently no help for the poor developer who wants to inherit a class and wants to figure out how to use the protected methods & properties ;)

Reinier Olislagers wrote

So apparently no help for the poor developer who wants to inherit a class and wants to figure out how to use the protected methods & properties ;)

The is also no help (near zero) for poor Michael, having to write all that documentation. Just documenting the Public and Published parts, was already a huge undertaking - and there are still more units that are completely undocumented (as you might know). So documenting the most used parts first, seem like a good path to take. ;-)

Regards,
- Graeme -

Oh, I completely agree that's the most sensible path.

Thought I could add some titbits while doing a search for Visibility: public, Visibility: default and Visibility: published. At least I tried...

Let me put it another way: when I have time, the inclination and knowledge and if it is actually fairly easy to do, I'll propose a patch for makeskel that changes
function result Visibility: default
into
function result Visibility: private, protected, public or published, depending on scope of the parent function
and
argument Visibility: default
into
argument Visibility: private, protected, public or published, depending on scope of the parent procedure/function

... unless the FPC gurus object to it

Now back to the grindstone...

No, why ? A function result has no visibility.
The comment is just a hint for the documenter, after all.

If you want to make a patch to specify the parent function's visibility, go ahead, but I think there are more useful things that can be done...

Michael.

Yes, in this case I & my friend grep (ok, Notepad++ in this case) are the documenter. It's easier to just go through all visibility: public and published properties.

If you want to make a patch to specify the parent function's visibility, go ahead, but I think there are more useful things that can be done...

Got you, it's certainly not one of my top priorities...

Thanks,
Reinier

Filed a patch: 22639
This also improves error reporting for missing source files.

Thanks,
Reinier