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 <[email protected]>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 >
