gcc visibility used by moz

[Tristan Wibberley]

Jason Merrill wrote:

> It seems that you have a different mental model of type visibility.  The 
> way I was thinking about it, if a type has hidden visibility, we can't 
> refer to it from outside its object.  Thus, it doesn't make sense for 
> members or objects with that type to have greater visibility because 
> even if people can call the accessor they can't do anything with the 
> return value.
 >
> However, I'm not attached to this in defiance of practical concerns. 
> What is your model of type visibility?

This isn't "type" visibility. Shared objects don't export "types" they 
export "symbols". The types are defined in headers and are thus known to 
exist - no visibility attributes will or should change that.

If the programmer had intended that the type should appear to not exist. 
it wouldn't be defined in a header #include-able by client code. The 
compiler should assume that the type exists and can be used if it is 
defined and shouldn't change attributes on other parts of the program.

In the examples above, client code that knows (via headers) that the 
classes exist should be able to get pointers to instances via exported 
functions, access any visible or virtual members, and pass the pointers 
back into visible functions of the shared object - or even dereference 
the pointers to pass by reference.

-- 
Tristan Wibberley

These opinions are my own, and do not reflect those of my employer.