lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject [lucy-dev] Symbol visibility refinements
Date Tue, 02 Apr 2013 23:10:53 GMT
Greets,

>From the standpoint of native shared objects on all the operating systems we
target, a symbol is either visible or it is not[1].  Since Clownfish
piggybacks on operating system support for dynamic loading, I think we should
align it more closely with those systems.

Therefore, I'd like to propose a couple refinements to rationalize symbol
visibility in Clownfish.

*   Eliminate both the `private` visibility specifier and explicit `parcel`
    visibility specifier.
*   Eliminate the ability to specify visibility for object member variables.

After the streamlining, classes, object methods, inert functions, and inert
variables would have two possible visibility levels:

*   `public`, meaning visible from outside the DSO.
*   unspecified, meaning DSO-scoped (or parcel-scoped -- same thing)

Removal of the `private` visibility specifier is justified because YAGNI --
the C storage class `static` implements everything we could want out of
`private`.

Removal of the `parcel` visibility specifier is justified because it is simply
superflous.  All we need is a default of DSO-scope (as advocated in the
Drepper DSO paper), and `public` as a way to expose a symbol beyond DSO scope.

The issue of symbol visibility for object member variables was discussed at
length several months ago, and today's proposed refinement simply brings us
into closer alignment with the decision reached at that time.  In the future,
we may wish to establish an official mechanism such as `friend`[2] for
exposing struct definitions to other classes within a parcel (e.g. `friend
class StringIterator;`), but right now the functionality is available via a
silly hack (defining e.g.  `C_CFISH_STRING` within the .c implementation file
for StringIterator to get at String's internals) and so the issue is not
pressing.

Marvin Humphrey

[1] Controversial features such as ELF `protected` and `internal` visibility
    notwithstanding.
[2] http://www.parashift.com/c++-faq-lite/friends-and-encap.html

Mime
View raw message