Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2026-10

Fwd: New Issue: Accessibility Declarations for FreePascal

5 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Martin Frb

Can someone comment on this?

Do we have C-like distinction between access and visible?

I would think not?

If you can access it you can see it, and vice versa? I can't think of any other case (i.e. where an identifier would be hidden by something that you can't access like in the example below)

We do have the reverse, that a public property/function can expose a private type (but not the name of the type, just its "content" (enum/members))

-------- Forwarded Message --------

Martin,

Last week, while we were discussing the FreePascal accessibility declarations, I began to wonder whether the private/strict private/protected/strict protected keywords really were accessibility values or visibility values.  In the reference manual, it uses both terms interchangeably.  It says, "The visibility of the different sections is...", but then in the text for each value, it uses verbiage like "can be accessed".  In C++, there are situtations where visibility vs. accessibility is an important distinction.  My go-to to expose this is hiding rules.  For example:

    int foo = 1;
    class C {
    private:
        int  foo {2};
    };
    class D : public C {
    public:
        void func()
        {
           // illegal because C::foo is visible here, but not accessible.
           // Because C::foo is visible, it hides ::foo.
           std::cout << foo << '\n';
        }
    };

Or another example:

    class C {
    public:
        int foo { 1 };
    };
    class D : public C {
    private:
        int foo { 2 };
    };
    int main()
    {
        D  obj;
        // illegal because D::foo is visible here, but not accessible.
        // Because D::foo is visible here, it hides C::foo.
        std::cout << obj.foo << '\n';
    }

My question is: In FreePascal, are there situations like this where the private/strict private/protected/strict protected names can hide other names at global scope?  Or at any "outer" scope, for that matter, if these constructs can be declared arbitrarily nested within other constructs, like in Ada.  If they all can hide names, to my mind, that rules out using visibility as any part of the description.  Instead, if none of them can hide other names, then perhaps all of them should be visibility values instead.  Or, if it's impossible to construct an example in FreePascal that can tell the difference, then perhaps I'm just splitting hairs.  :)

Regards,
Todd Allen

Reply by email

Unknown author
to Martin Frb

I can't answer your question directly, but what I can tell you is that the last time I tried to use lazarius, (which admittedly was several years ago), it wasn't the least bit accessible.  Screen readers pick up on these elements to know what's visible on the screen, and what's an roll for screen reader use only, such as a label for a visible element.  I have mentioned that lazarus IDE is not accessible multiple times in the past, and yet, nobody seems to be interested in doing anything about it.  Perhaps this question will shed some light on the reasons why it isn't accessible.

Or, for all I know, it's 100 percent accessible, because someone fixed it, but I find that generally, if an application is not accessible, that rarely changes just from standard work on it.  99 percent of the time, the application remains inaccessible, because nonstandard controls are used, or accessibility rolls are not coded on the nonstandard controls that are used, usually both.

I'm guessing if someone were to investigate, the difference between the two things you're asking might actually be more than is currently expected, but then again, depending on terminology, I could be completely wrong, and the things that are being discussed have nothing at all to do with accessibility, wouldn't be the first time terms have gotten mixed up when trying to solve accessibility issues.

Martin Frb wrote 97 lines
Can someone comment on this? Do we have C-like distinction between access and visible? I would think not? If you can access it you can see it, and vice versa? I can't think of any other case (i.e. where an identifier would be hidden by something that you can't access like in the example below) We do have the reverse, that a public property/function can expose a private type (but not the name of the type, just its "content" (enum/members)) -------- Forwarded Message -------- Martin, Last week, while we were discussing the FreePascal accessibility declarations, I began to wonder whether the private/strict private/protected/strict protected keywords really were accessibility values or visibility values.  In the reference manual, it uses both terms interchangeably.  It says, "The visibility of the different sections is...", but then in the text for each value, it uses verbiage like "can be accessed".  In C++, there are situtations where visibility vs. accessibility is an important distinction.  My go-to to expose this is hiding rules.  For example: int foo = 1; class C { private:    int  foo {2}; }; class D : public C { public:    void func()    {       // illegal because C::foo is visible here, but not accessible.       // Because C::foo is visible, it hides ::foo.       std::cout << foo << '\n';    } }; Or another example: class C { public:    int foo { 1 }; }; class D : public C { private:    int foo { 2 }; }; int main() {    D  obj;    // illegal because D::foo is visible here, but not accessible.    // Because D::foo is visible here, it hides C::foo.    std::cout << obj.foo << '\n'; } My question is: In FreePascal, are there situations like this where the private/strict private/protected/strict protected names can hide other names at global scope?  Or at any "outer" scope, for that matter, if these constructs can be declared arbitrarily nested within other constructs, like in Ada.  If they all can hide names, to my mind, that rules out using visibility as any part of the description.  Instead, if none of them can hide other names, then perhaps all of them should be visibility values instead.  Or, if it's impossible to construct an example in FreePascal that can tell the difference, then perhaps I'm just splitting hairs.  :) Regards, Todd Allen _______________________________________________ fpc-devel maillist https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply by email

Martin Frb
to Unknown author

Sorry "screen reader" is the wrong "accessibility" here.

The below is about debug info, especially DWARF.  I am in the process of requesting some additions so FPC can better represent its data.

In DWARF accessibility describes private/protected/public sections in classes/records/structures.

Travis Siegel wrote 11 lines
I can't answer your question directly, but what I can tell you is that the last time I tried to use lazarius, (which admittedly was several years ago), it wasn't the least bit accessible. Screen readers pick up on these elements to know what's visible on the screen, and what's an roll for screen reader use only, such as a label for a visible element.  I have mentioned that lazarus IDE is not accessible multiple times in the past, and yet, nobody seems to be interested in doing anything about it. Perhaps this question will shed some light on the reasons why it isn't accessible.

Reply by email

Tomas Hajny
to Martin Frb: Can someone comment on this? Do we have C-like distinction between access and visible? I…

On 2026-10-19 18:38, Martin Frb via fpc-devel wrote:

Hi,

Show quoted text 13 lines
Can someone comment on this? Do we have C-like distinction between access and visible? I would think not? If you can access it you can see it, and vice versa? I can't think of any other case (i.e. where an identifier would be hidden by something that you can't access like in the example below) We do have the reverse, that a public property/function can expose a private type (but not the name of the type, just its "content" (enum/members))

Equally to you, I don't think that FPC could distinguish accessibility from visibility. Obviously, there are cases when some declaration / definition "hides" something by using the same identifier for something else, but there are still ways allowing you to access the original "hidden" declaration. As an example, you may define a method M in some class (TC1), then create a new method with the same name of M in a child class (TC2) effectively meaning that you cannot access the original method M defined in TC1 from within TC2 directly, but you can still access it by typecasting the variable of type TC2 to TC1 and calling it that way. However, Similarly, using the same identifier in outer scope and in an inner scope (e.g. a global and local variables with the same name) "hides" the global identifier within the inner scope (e.g. in a procedure) in the sense that you cannot access it using the original identifier any longer, but you can still access it using a fully qualified name by prefixing it with a unit or program name.

Tomas

Show quoted text 64 lines
-------- Forwarded Message -------- Martin, Last week, while we were discussing the FreePascal accessibility declarations, I began to wonder whether the private/strict private/protected/strict protected keywords really were accessibility values or visibility values. In the reference manual, it uses both terms interchangeably. It says, "The visibility of the different sections is...", but then in the text for each value, it uses verbiage like "can be accessed". In C++, there are situtations where visibility vs. accessibility is an important distinction. My go-to to expose this is hiding rules. For example: > int foo = 1; > > class C { > private: > int foo {2}; > }; > > class D : public C { > public: > void func() > { > // illegal because C::foo is visible here, but not accessible. > // Because C::foo is visible, it hides ::foo. > std::cout << foo << '\n'; > } > }; Or another example: > class C { > public: > int foo { 1 }; > }; > > class D : public C { > private: > int foo { 2 }; > }; > > int main() > { > D obj; > // illegal because D::foo is visible here, but not accessible. > // Because D::foo is visible here, it hides C::foo. > std::cout << obj.foo << '\n'; > } My question is: In FreePascal, are there situations like this where the private/strict private/protected/strict protected names can hide other names at global scope? Or at any "outer" scope, for that matter, if these constructs can be declared arbitrarily nested within other constructs, like in Ada. If they all can hide names, to my mind, that rules out using visibility as any part of the description. Instead, if none of them can hide other names, then perhaps all of them should be visibility values instead. Or, if it's impossible to construct an example in FreePascal that can tell the difference, then perhaps I'm just splitting hairs. :) Regards, Todd Allen

Reply by email

Marco van de Voort
to Martin Frb: Can someone comment on this? Do we have C-like distinction between access and visible? I…

Op 19-10-2026 om 18:38 schreef Martin Frb via fpc-devel:

Show quoted text 14 lines
Can someone comment on this? Do we have C-like distinction between access and visible? I would think not? If you can access it you can see it, and vice versa? I can't think of any other case (i.e. where an identifier would be hidden by something that you can't access like in the example below) We do have the reverse, that a public property/function can expose a private type (but not the name of the type, just its "content" (enum/members))

You can't access those symbols with the unqualified name in Pascal either, but you can reach them with unitname prefixes or typecasting self.

Reply by email