traits getProtection

[deadalnix]

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.

>> 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.

In general, I'm not convinced by the authoritative argument. Both Andrei 
and Walter are skilled persons, but they can be wrong, especially when 
they don't agree.

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.

>> 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.