On Friday, February 17, 2012 20:02:53 Timon Gehr wrote:
> I understand what NVI is. It is just that private methods
> overridable from a different module don't have many merits,
> regardless of how NVI is apparently sometimes implemented in C++.
> The fact that C++ has overridable private methods i
On Friday, 17 February 2012 at 18:35:38 UTC, Jonathan M Davis
wrote:
On Friday, February 17, 2012 09:03:32 Steven Schveighoffer
wrote:
On Mon, 13 Feb 2012 21:05:35 -0500, Jonathan M Davis
wrote:
> On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
>> On 02/14/2012 02:16 AM, Jonathan M D
On Friday, February 17, 2012 09:03:32 Steven Schveighoffer wrote:
> On Mon, 13 Feb 2012 21:05:35 -0500, Jonathan M Davis
>
> wrote:
> > On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
> >> On 02/14/2012 02:16 AM, Jonathan M Davis wrote:
> >>
> >> Well, not being able override what canno
On Friday, February 17, 2012 10:18:32 Andrei Alexandrescu wrote:
> I agree. Walter and I chalked that up to a bug in TDPL that will be
> superseded by a different implementation.
Good to hear!
- Jonathan M Davis
On 2/17/12 8:03 AM, Steven Schveighoffer wrote:
On Mon, 13 Feb 2012 21:05:35 -0500, Jonathan M Davis
wrote:
On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
On 02/14/2012 02:16 AM, Jonathan M Davis wrote:
Well, not being able override what cannot be accesses is a quite basic
requir
On Mon, 13 Feb 2012 21:05:35 -0500, Jonathan M Davis
wrote:
On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
On 02/14/2012 02:16 AM, Jonathan M Davis wrote:
Well, not being able override what cannot be accesses is a quite basic
requirement of security. Private members cannot be ov
On Tuesday, February 14, 2012 21:13:46 Daniel Murphy wrote:
> > private and protected are automatically non-virtual
>
> You've said that twice now, I think you mean private and package.
Yes. You're right. The excess of p's is confusing me, I guess.
public and protected are automatically virtual.
> private and protected are automatically non-virtual
You've said that twice now, I think you mean private and package.
On Tuesday, February 14, 2012 04:39:18 Timon Gehr wrote:
> On 02/14/2012 03:54 AM, Jonathan M Davis wrote:
> > On Tuesday, February 14, 2012 03:45:54 Timon Gehr wrote:
> >> On 02/14/2012 03:05 AM, Jonathan M Davis wrote:
> >>> On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
> On 02/14
On 02/14/2012 03:54 AM, Jonathan M Davis wrote:
On Tuesday, February 14, 2012 03:45:54 Timon Gehr wrote:
On 02/14/2012 03:05 AM, Jonathan M Davis wrote:
On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
On 02/14/2012 02:16 AM, Jonathan M Davis wrote:
Well, not being able override what
On Tuesday, February 14, 2012 03:45:54 Timon Gehr wrote:
> On 02/14/2012 03:05 AM, Jonathan M Davis wrote:
> > On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
> >> On 02/14/2012 02:16 AM, Jonathan M Davis wrote:
> >>
> >> Well, not being able override what cannot be accesses is a quite ba
On 02/14/2012 03:05 AM, Jonathan M Davis wrote:
On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
On 02/14/2012 02:16 AM, Jonathan M Davis wrote:
Well, not being able override what cannot be accesses is a quite basic
requirement of security. Private members cannot be overriden in a
dif
On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
> On 02/14/2012 02:16 AM, Jonathan M Davis wrote:
> 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.
Have you ever read up on NVI?
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), le
On 02/14/2012 01:55 AM, Timon Gehr wrote:
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 co
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 th
On 02/14/2012 01:28 AM, Jonathan M Davis wrote:
On Tuesday, February 14, 2012 00:36:31 Timon Gehr wrote:
On 02/14/2012 12:26 AM, Jonathan M Davis wrote:
On Tuesday, February 14, 2012 00:15:40 Martin Nowak wrote:
Can you elaborate on what issues you see with NVI. After all it's only
the final p
On Tue, 14 Feb 2012 00:26:14 +0100, Jonathan M Davis
wrote:
On Tuesday, February 14, 2012 00:15:40 Martin Nowak wrote:
Can you elaborate on what issues you see with NVI. After all it's only
the
final public
method that needs to call the virtual private methods.
As I explain in that bug r
On Tuesday, February 14, 2012 00:36:31 Timon Gehr wrote:
> On 02/14/2012 12:26 AM, Jonathan M Davis wrote:
> > On Tuesday, February 14, 2012 00:15:40 Martin Nowak wrote:
> >> Can you elaborate on what issues you see with NVI. After all it's only
> >> the final public
> >> method that needs to call
On 02/14/2012 12:26 AM, Jonathan M Davis wrote:
On Tuesday, February 14, 2012 00:15:40 Martin Nowak wrote:
Can you elaborate on what issues you see with NVI. After all it's only the
final public
method that needs to call the virtual private methods.
As I explain in that bug report, NVI can be
On Tuesday, February 14, 2012 00:15:40 Martin Nowak wrote:
> Can you elaborate on what issues you see with NVI. After all it's only the
> final public
> method that needs to call the virtual private methods.
As I explain in that bug report, NVI can be acheived with protected rather
than private.
On Mon, 13 Feb 2012 19:07:20 +0100, Jonathan M Davis
wrote:
On Sunday, February 12, 2012 19:32:28 David Nadlinger wrote:
On 2/12/12 7:28 PM, Martin Nowak wrote:
> The shallow distinction of visibility vs. accessibility breaks the
> module system because
> one can't safely add a private symbo
On Sunday, February 12, 2012 19:32:28 David Nadlinger wrote:
> On 2/12/12 7:28 PM, Martin Nowak wrote:
> > The shallow distinction of visibility vs. accessibility breaks the
> > module system because
> > one can't safely add a private symbol without possibly affecting every
> > dependent module.
>
Agreed with David. I find these things a pointless waste of time:
module a;
private {
struct foo {
}
}
module b;
void foo() { }
import a;
import b;
void main() {
foo();
}
main.d(7): Error: a.foo at a.d(3) conflicts with b.foo at b.d(2)
main.d(7): Error: structliteral has no effect
On Sun, 12 Feb 2012 19:32:28 +0100, David Nadlinger
wrote:
On 2/12/12 7:28 PM, Martin Nowak wrote:
The shallow distinction of visibility vs. accessibility breaks the
module system because
one can't safely add a private symbol without possibly affecting every
dependent module.
Thus we're back
On 2/12/12 7:28 PM, Martin Nowak wrote:
The shallow distinction of visibility vs. accessibility breaks the
module system because
one can't safely add a private symbol without possibly affecting every
dependent module.
Thus we're back at using underscore names to protect from that.
Yes, and this
I made a pull request to fix private/package access checks.
https://github.com/D-Programming-Language/dmd/pull/669
Now I'm wondering if that goes into the right direction.
The shallow distinction of visibility vs. accessibility breaks the module
system because
one can't safely add a private sy
27 matches
Mail list logo
