On Wednesday, April 04, 2012 09:04:41 deadalnix wrote:
> 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@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.

Well, that's the way that it works in C++. And it makes sense if you think about it. The derived class' method is private to _it_, not the base class, so it can still call it, even if it can't call the base class version.

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

They are and they aren't. There are major issues in allowing the overriding of non-virtual functions. It's far less error-prone to simply make it so that a class' member functions are always virtual unless the compiler can determine that it can make them non-virtual (which can only happen when they're final and don't override anything). D took the same route as Java in this regard. And because it took that route, the programmer has _zero_ control over the virtuality of a function, and it's very much tied to the access level of a function. That design decision is _not_ going to be changed, so the virtuality of a function is defined by its access level.

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

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

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

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.

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

- Jonathan M Davis

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.

On Wednesday, 4 April 2012 at 07:05:59 UTC, deadalnix wrote:
> It should be provided as lib by std.traits . And no need for language changes.

It wouldn't account for the case I actually want: checking
for export.

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

On Mon, 02 Apr 2012 19:10:01 +0200, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Monday, April 02, 2012 13:26:05 Dmitry Olshansky wrote:
>> It's all nice and well, but I believe part of the reason of say private
>> protection is that user is never ever able to see(!) it. Thus it user
>> can't depend on private members being there, which is a good thing.
>> If I read it right, the technique you present allows user code to depend
>> on private functions being there.
>> I argue that we shouldn't even provide a _possibility_ for external
>> stuff to depend on private members.
>> Same argument in limited scope goes for protected.
>
> As it stands, private has _no_ effect on symbol visibility. All it affects is
> symbol accessibility. For instance, if you create a private alias in a module,
> it affects every module that imports your module, or if you create a function
> which causes an overload conflict, it creates an overload conflict regardless of
> whether it's private or not. C++ is the same way. Access modifiers are just
> that, _access_ modifieres. They _only_ affect accessibility, not visibility.
>
Access modification really makes sense for nested scopes.
After all you can have access to a value of a protected type.
In this case changing the visibility could lead to accidental
mismatches. This behavior is taken from C++ and it makes sense.

Due to the .h/.cpp separation you'll also have most of the
implementation symbols invisible. That's where the C++ model
doesn't really map to D if 'import everything' remains the default.

Le 04/04/2012 19:43, Jonathan M Davis a écrit :
> 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.
>

New version of gcc implemented extensions to not export everything in posix world. IIRC, clang provide this as well.

Again, this is an implementation problem and shouldn't be fixed with language design decisions.

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

This is why extensions are made for C/C++ compilers on posix systems.

> 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 understand your point about this being weird in interfaces. Now, granted that it is likely to be like this in interfaces, let's make things consistent.

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

I have to agree. The difference, as stated in TDPL, is that you cannot call the private one, only override it.

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

This is possible, but this have quite a lot of implication, on reflection for instance. What about both being defined in the same module, where private stuff are accessible.

Le 04/04/2012 15:52, Adam D. Ruppe a écrit :
> On Wednesday, 4 April 2012 at 07:05:59 UTC, deadalnix wrote:
>> It should be provided as lib by std.traits . And no need for language
>> changes.
>
> It wouldn't account for the case I actually want: checking
> for export.

Good point. You are right, it is needed in reflection.