lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Logan Bell <>
Subject Re: [lucy-dev] Symbol visibility refinements
Date Thu, 04 Apr 2013 06:08:09 GMT
Hi Marvin,

I think it's great that you're presenting this change in light of the
material we've been reading in Drepper's paper, which means I actually have
a better understanding of your proposal. :) Below I have included a few
questions regarding the proposal and also seeking clarification around
Clownfish syntax particulars.


On Tue, Apr 2, 2013 at 4:10 PM, Marvin Humphrey <>wrote:

> 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.

Does parcel imply any visibility level? In my mind I always thought of
parcel as a package specifier.

> *   Eliminate the ability to specify visibility for object member
> variables.

Would all object member variables and methods be private by default?
Further, I believe this means that if we wanted these variables to be
public they would be accessible via accessors?

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

In the context clownfish what does the inert mean? Immutable?

> *   `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]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message