traits getProtection

[Jonathan M Davis]

On Wednesday, April 04, 2012 15:49:59 deadalnix wrote:
> Le 04/04/2012 10:41, Jonathan M Davis a écrit :
> >> Plus, this isn't a real issue, because the final keyword exists.
> > 
> > It's a _huge_ issue, because it means that nearly every single private
> > function in a class in D will need to be marked with final in order for it
> > to be non-virtual and inlinable. The default becomes inefficient, and all
> > just for NVI.
> 
> OK, let me restate this. This isn't a language design issue, this is an
> implementation issue. Java and C# finalize function for ages. See below.
> 
> >> At the end, for performance concerns, what we want is that the compiler
> >> or the linker were able to finalize methods that have no override, not
> >> some dirty trick that break larger more important conception principles.
> > 
> > Because of how the compilation model works, that's impossible. No class
> > can
> > know all of its derived classes. Not only are classes compiled completely
> > independently of their derived classes, but derived classes could be
> > linked in dynamically at runtime, and those classes could have been
> > written long after the base class was written and compiled. So, unless
> > the programmer explicitly marks a function as final, there's no way that
> > the compiler can know that that function won't be overridden.
> 
> Unless something is marked as export, no code can be linked to it at
> runtime. So the linker could finalize any function that isn't export - a
> vast majority. It doesn't, I admit. But this is definitively a
> implementation issue, and fixing it by language design decision is a
> mistake.

In Posix-land, _everything_ is exported. AFAK, this whole idea of marking 
functions as exported or not is a Windows-only thing. And honestly, it's one 
of my biggest complaints about programming in Windows. It's seriously annoying
to have to deal with constantly exporting stuff on Windows. On Linux, it
_just works_. IMHO, shared libraries is one area where Windows seriously
dropped the ball in comparison to *nix. In my experience, there are _far_
fewer issues with them on Linux than Windows with its export and its nonsense
of having to link against a specific version of a static library to be able
to link against a dynamic one.

Regardless, export is a Windows-only thing and is completely unusable for any
kind of optimizations in the general case.

> >> It is not that simple. First, it introduce an inconsistency between
> >> interfaces and classes for no real reasons. The only difference between
> >> classes and interfaces should be that interface cannot have member data,
> >> and you can inherit from multiple interfaces. Interface have been
> >> created to solve the problems that exists for multiple inheritance, and
> >> that is enough to solve that problem. Everything else is, again, lack of
> >> separation of concerns.
> > 
> > private is _not_ going to become virtual in classes. I believe that Walter
> > has stated that it will remain non-virtual (though I'd have to dig
> > through the newsgroup for the exact quote). The only question is how to
> > handle it in interfaces, and as far as I know, the intention is to make
> > interfaces follow TDPL with regards to private.
> 
> I know, but Andrei seems to disagree. I also have to dig, to find it,
> but I guess we can trust each other on that.

Actually, I believe that Andrei agreed with Walter in the same thread that 
Walter agreed not to make private virtual, but I'd have to go dig it up, and 
unfortunately, I always have a horrible time tracking down posts. I think that 
it was within the last few months though.

> If I restate the question, what is the benefit of having classes and
> interfaces behaving differently on this point ? TDPL make it pretty
> clear how it should be handled in interfaces. Classes should work the
> same way. Fixing an implementation issue isn't a valid reason.

Allowing private in interfaces is already getting weird, because of what 
interfaces are for and how they work, and doing so is already arguably special 
casing things. Certainly, the reasons for having private in interfaces is 
_completely_ different from having it in classes. private in interfaces is 
_only_ intended for NVI, whereas NVI is _not_ the reason for having private in 
classes, and in fact is fairly rare thing to do with private. I don't think 
that it's _possible_ to overload private in any language other than C++, and I 
believe that a large number of C++ programmers are completely unaware that 
it's possible in C++. Making private in classes work the same way as it does 
in interfaces would be detrimental to classes just for an idiom which many 
programmers _never_ use (though it _is_ a useful one) - and one which works 
just fine with protected.

I don't believe that it's currently the plan, but I don't see any problem with 
just making it so that protected is used in interfaces for NVI instead of 
private. As I already pointed out, in C++, the derived classes can already 
call their versions of the NVI functions, since they're private to _them_, not 
the base class, even if they can't call the base class implementation (if 
there even is one), but interfaces don't _have_ a base class implementation, 
so there's nothing to protect from being called anyway. So, using protected 
wouldn't really change anything, and it would be completely consistent with 
how protected is used normally.

> >> Second, the same method can be declared in the base class and in an
> >> interface, and in this case, we cause compile error for nothing.
> > 
> > Why would there be a compilation error? The base class cannot call the
> > interface's private function, so any reference to that function would be
> > the base class' function.
> 
> You have a class C and an interface I, both define the private method foo.
> 
> In MyClass : C, I, if I define foo, I get an error because foo isn't
> virtual in C, and if I don't, I don't implement I.

All it has to do is ignore C's private function in MyClass, because it's non-
virtual and _can't_ be overloaded.

- Jonathan M Davis