lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Logan Bell <loganb...@gmail.com>
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.

Thanks,
Logan

On Tue, Apr 2, 2013 at 4:10 PM, Marvin Humphrey <marvin@rectangular.com>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.


+1

>
> 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] http://www.parashift.com/c++-faq-lite/friends-and-encap.html
>

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