traits getProtection

[deadalnix]

Le 04/04/2012 04:48, Jonathan M Davis a écrit :
> On Tuesday, April 03, 2012 08:23:49 deadalnix wrote:
>> Le 02/04/2012 22:59, Simen Kjærås a écrit :
>>> On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix<deadalnix at gmail.com>  wrote:
>>>>> Now, there are a number of people very unhappy about this state of
>>>>> affairs and
>>>>> want private to hide symbols as well (personally, I think that the
>>>>> fact that
>>>>> it makes private aliases effectively useless is reason enough to
>>>>> seriously
>>>>> reconsider the current behavior), but I don't know if there's any
>>>>> real chance
>>>>> of convincing Walter or not.
>>>>
>>>> This would be a huge mistake. For instance, private method are
>>>> sometime meant to be overridden in subclasses, which is impossible if
>>>> symbol is inaccessible.
>>>>
>>>> NVI for instance would be impossible in such a situation.
>>>
>>> NVI is perfectly possible with protected.
>>
>> You'll loose the ability to define a function, without being able to
>> call it.
>
> Except that that doesn't even actually work as discussed in this thread:
>
> http://www.digitalmars.com/d/archives/digitalmars/D/Re_Module-
> level_accessibility_118209.html#N118329
>
> The derived class overrode the function, so it can call it. It may not be able
> to call the base class version, but it can call its own.
>

It shouldn't be able to do so. This should be reserved for protected 
methods.

> Sure, NVI is great, but it works just as well with protected. private doesn't
> actually prevent you from calling the function in the derived class, and even
> if it did, it's _not_ worth the cost of making private virtual by default. And
> as D lets the compiler control virtuality, unlike C++, it doesn't make any
> sense to make it so that the programmer can specifically make a private
> function virtual to work with NVI. So, it just makes more sense to use
> protected to do NVI.
>

Visibility and virtuality are 2 completely orthogonal concerns. Mixing 
both is a bad design decision, what ever is the rational behind it. 
Separation of concerns is more important.

Plus, this isn't a real issue, because the final keyword exists.

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.

> Now, it may be different with interfaces. TDPL specifically talks about using
> private for NVI with _interfaces_, not classes. Doing that sort of thing with
> interfaces requires special treatment already, and it doesn't affect efficiency
> like making private always virtual would, so that should be okay. In the
> general case though, it's just far better to use protected to do NVI with
> classes and let private be non-virtual and therefore efficient by default rather
> than inefficient by default.
>
> - Jonathan M Davis

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.

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.