After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 697777 - internal fields appear in public header/struct
internal fields appear in public header/struct
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: Structs
0.18.x
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2013-04-11 10:41 UTC by Simon McVittie
Modified: 2018-05-22 14:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Preliminary support for hiding internal instance members (5.24 KB, patch)
2013-08-25 10:54 UTC, Maciej (Matthew) Piechotka
none Details | Review

Description Simon McVittie 2013-04-11 10:41:15 UTC
Until recently, libfolks-telepathy had this:

public class Tpf.PersonaStore : Folks.PersonaStore
{
  ...
  internal SmallSet<string> _supported_fields;
  internal Set<string> _supported_fields_ro;
  ...
}

When compiled without using --internal-vapi or --internal-header, this results in the C struct in the public header looking like this:

    struct _TpfPersonaStore {
            FolksPersonaStore parent_instance;
            TpfPersonaStorePrivate * priv;
            FolksSmallSet* _supported_fields;
            GeeSet* _supported_fields_ro;
    };

and the header from the .vapi for FolksSmallSet being #include'd.

Unfortunately, FolksSmallSet is declared in a header that isn't installed (it's a private C implementation of Gee.Set optimized for small or empty sets), so this broke the build of dependent projects.

Ideally, adding "internal Foo" to a class shouldn't result in changes to the public header (although I can't really see a way to to achieve that).
Comment 1 Maciej (Matthew) Piechotka 2013-08-02 15:40:53 UTC
(In reply to comment #0)
> Ideally, adding "internal Foo" to a class shouldn't result in changes to the
> public header (although I can't really see a way to to achieve that).

Since the internal classes can have access to *Private it should be possible to put internal symbols there (If you already have symbols defined such change would change the ABI).
Comment 2 Maciej (Matthew) Piechotka 2013-08-25 10:54:02 UTC
Created attachment 253051 [details] [review]
Preliminary support for hiding internal instance members

This is not yet working for multiple files as the code generation for Private needs to be altered.
Comment 3 GNOME Infrastructure Team 2018-05-22 14:45:56 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/373.