documentation of visibility of variable

[wriedmann]

Hi Robert,
we were not able to find a page where the visibility of the variables was described.
I mean one of these:

Modifiers An optional list of modifiers that specify the visibility or scope of the entity, such as PUBLIC, PROTECTED, HIDDEN, INTERNAL, SEALED, ABSTRACT or STATIC.

I was searching what exactly "INTERNAL" means.
Thank you very much!
Wolfgang

[Chris]

Hi Wolfgang,

INTERNAL means visible only within the same assembly (exe or dll). It can be combined with the other modifiers like PROTECT, EXTERNAL etc, so "INTERNAL PROTECTED" means visible only inside the same class and its subclasses, which are defined in the same assembly where the CLASS/field etc is defined (not in subclasses in another library).

Good idea for a help topic to add, if you have any other suggestions for help topics, please let us know!

[wriedmann]

Hi Chris,
ok, thank you very much!
But that does not explains something for me.
Andreas yesterday has downloaded the current source of the SQLRDD from Github, and since he does not likes to work with VS, he has moved the source to a XIDE project, but had a compiler error first in the constructor of the SQLRDD class because a property of the father class DBFVFP was declared as "internal". Strange enough, after changing the name of the assembly, the error was gone.
Wolfgang

[robert]

Wolfgang,
There is an [InternalsVisibleTo] attribute in the XSharp.RDD assembly that makes some of its types accessible by the SQLRDD class.

Robert

[wriedmann]

Hi Robert,
thank you very much for this explanation! It helps a lot to understand it better!
Wolfgang

[robert]

Wolfgang,
I am not a real fan of the "InternalsVisibleTo" attribute. So I'll probably will make these methods/properties PROTECTED INTERNAL later, which means that they can also be called from subclasses.
I am using INTERNAL because I do not want these methods / properties to become part of the documented public API, so I can change them later without breaking other peoples code.

Robert

[wriedmann]

Hi Robert,
I agree with you that this attribute may be a bit confusing.
About the architecture of the driver: since there are several SQL dialects out: what about splitting this RDD in a main part that contains maybe the SQL Server driver and the SQLite driver that are part of the standard .NET Framework, and delegate the other drivers to loadable modules?
In that manner people can add drivers later for their own SQL dialect, not only PostgreSQL, MySQL and Oracle, but also others too?
And defining an interface for these modules it makes it easier for others to extend it later.
Wolfgang
P.S. we are willing to collaborate on the PostgreSQL driver. In fact, Andreas is looking at the sources because of this