On 02/14/2012 02:16 AM, Jonathan M Davis wrote:
On Tuesday, February 14, 2012 01:55:51 Timon Gehr wrote:
On 02/14/2012 01:28 AM, Jonathan M Davis wrote:
It would break information hiding. A private method declared in a
different module is not supposed to be visible (hopefully will get
fixed), let alone overrideable.
You misunderstand then. Private symbols are most definitely visible. Access
modifiers do _not_ affect visibility, only accessibility. Private symbols are
visible _by design_. That's how it works in C++, and D inherited that. The
whole point of this thread is to discuss whether access modifiers should affect
visibility, but right now they _do_, and it's _on purpose_ that they do. It's
not a bug.
It is a bug on purpose.
As it stands, if I declare a private function which conflicts with a public
function, the compiler will complain. For example, If I were to add a private
abs function to std.file which took an int, then any module which imported both
std.math and std.file would have to use std.math.abs instead of just abs,
because there would be a conflict. The fact that std.file's abs was private
wouldn't mean anything to overload resolution.
Borken.
In fact, just recently, a private abs function was added to core.time for what
it needed, and it caused problems. It had to be changed to _abs to not screw
up std.math.abs.
Exactly what I am saying. This is laughable (!) and should vanish from
Ds otherwise very sane approach at modularity.
The whole point of this thread is to discuss whether access modifiers should be
changed to affect visibility rather than access.
Most definitely yes. The only hindrance are implementation issues.
Regardless, I'm against making private virtual because of the needless
performance hit.
There are no performance implications because the compiler has the whole
module ready to analyse. Therefore it can de-virtualise any calls to
private members that are never overridden. A trivial addition to the
class layout could furthermore allow the compiler to remove the vtable
entry for such a member function entirely (essentially, virtual private
members would get negative vtable offsets). I actually think that should
be implemented in order to get a potential TDPL error off the table.
No. It can't. Because a derived class in an entirely different module could
override the private function. private does _not_ affect visibility.
Well, not being able override what cannot be accesses is a quite basic
requirement of security. Private members cannot be overriden in a
different module.
The whole idea of overriding private for NVI is to allow derived classes to
override the
private function's implementation but not call it.
This is confusing method implementation with overriding. I just read the
relevant sections of TDPL:
"D fully supports NVI by providing _specific guarantees_ when
*interfaces* use access specifiers."
It is an explicit special case because private wouldn't have much of a
meaning for interfaces otherwise. This means private interface members
would not be hidden, they are special _already_.
If private becomes virtual, then the compiler loses the ability to inline
non-final private functions
unlessit can guarantee that it's dealing with that exact type, which it
usually can't do in the type's own member functions.
The optimisation works for all private class members. The issue is the
virtual table layout for separate compilation with .di files, therefore
it is not a good idea to make private methods virtual. But that is not
required to satisfy TDPL anyway:
As far as I can see TDPL only requires private *interface* members to be
implementable. That is not a problem at all, interface vtbls use
thunking anyway. Therefore the private members could just be plugged
there and be called virtually through base interface calls and
non-virtually otherwise.
