www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Question about 'final' keyword.

reply AjO <AjO_member pathlink.com> writes:
Hello everyone!

I was today looking into the similarities/differences of Java and D. I
experimented with the 'final' keyword. In Java, when used with class
declaration, guarantees that one cannot subclass from a 'final' class. Now, I
tried the similar approach in D, and to my surprise, noticed that with the code
provided below, only the methods become final. This means that I can subclass a
'final' class in D with no problem. All I can't do is override the methods in
that 'final' class. Is this desired behaviour, or is the something wrong with my
snippet?

import std.stdio;

final class Kid
{
void a()
{
writefln("a() in Kid");
}

void b()
{
writefln("b() in Kid");
}
}

class Youngster : Kid
{
/*
void a()
{
// Uncommenting causes a compiler error.
}
*/

void c()
{
a();
}

void d()
{
b();
}
}

int main(char[][] argumentTable)
{
Kid k = new Kid();

k.a();
k.b();

Youngster g = new Youngster();

g.a();
g.b();
g.c();
g.d();

return 0;
}
Dec 05 2005
next sibling parent reply Chris Lajoie <ctlajoie yahoo.com> writes:

find out that the StringBuilder class was marked 'sealed' (aka 'final'). 
All I wanted to do was extend it's functionality, I didn't want to override 
its methods. I don't see any reason why it shouldn't be possible, since the 
purpose of marking a class final is to prevent tampering with its
implimentation. 
It may well be a bug though, since it is clear from your code that you don't 
want anyone to be able to subclass it, regardless of whether people find 
it irritating.

Chris


 Hello everyone!
 
 I was today looking into the similarities/differences of Java and D. I
 experimented with the 'final' keyword. In Java, when used with class
 declaration, guarantees that one cannot subclass from a 'final' class.
 Now, I tried the similar approach in D, and to my surprise, noticed
 that with the code provided below, only the methods become final. This
 means that I can subclass a 'final' class in D with no problem. All I
 can't do is override the methods in that 'final' class. Is this
 desired behaviour, or is the something wrong with my snippet?
 
 import std.stdio;
 
 final class Kid
 {
 void a()
 {
 writefln("a() in Kid");
 }
 void b()
 {
 writefln("b() in Kid");
 }
 }
 class Youngster : Kid
 {
 /*
 void a()
 {
 // Uncommenting causes a compiler error.
 }
 */
 void c()
 {
 a();
 }
 void d()
 {
 b();
 }
 }
 int main(char[][] argumentTable)
 {
 Kid k = new Kid();
 k.a();
 k.b();
 Youngster g = new Youngster();
 
 g.a();
 g.b();
 g.c();
 g.d();
 return 0;
 }
Dec 05 2005
next sibling parent reply Kramer <Kramer_member pathlink.com> writes:
Also, 'final' I'm guessing would remove the need for methods to be virtual, thus
potentially speeding up those methods, no?

-Kramer

In article <a8deea61394d8c7c7b84971d1f0 news.digitalmars.com>, Chris Lajoie
says...


find out that the StringBuilder class was marked 'sealed' (aka 'final'). 
All I wanted to do was extend it's functionality, I didn't want to override 
its methods. I don't see any reason why it shouldn't be possible, since the 
purpose of marking a class final is to prevent tampering with its
implimentation. 
It may well be a bug though, since it is clear from your code that you don't 
want anyone to be able to subclass it, regardless of whether people find 
it irritating.

Chris


 Hello everyone!
 
 I was today looking into the similarities/differences of Java and D. I
 experimented with the 'final' keyword. In Java, when used with class
 declaration, guarantees that one cannot subclass from a 'final' class.
 Now, I tried the similar approach in D, and to my surprise, noticed
 that with the code provided below, only the methods become final. This
 means that I can subclass a 'final' class in D with no problem. All I
 can't do is override the methods in that 'final' class. Is this
 desired behaviour, or is the something wrong with my snippet?
 
 import std.stdio;
 
 final class Kid
 {
 void a()
 {
 writefln("a() in Kid");
 }
 void b()
 {
 writefln("b() in Kid");
 }
 }
 class Youngster : Kid
 {
 /*
 void a()
 {
 // Uncommenting causes a compiler error.
 }
 */
 void c()
 {
 a();
 }
 void d()
 {
 b();
 }
 }
 int main(char[][] argumentTable)
 {
 Kid k = new Kid();
 k.a();
 k.b();
 Youngster g = new Youngster();
 
 g.a();
 g.b();
 g.c();
 g.d();
 return 0;
 }
Dec 05 2005
parent reply AjO <AjO_member pathlink.com> writes:
In article <dn29eo$26d2$1 digitaldaemon.com>, Kramer says...

Also, 'final' I'm guessing would remove the need for methods to be virtual, thus
potentially speeding up those methods, no?

-Kramer


Well, it says in the D spec that there is no virtual table. Or that's what it
says at: http://www.digitalmars.com/d/module.html
Dec 05 2005
next sibling parent Kramer <Kramer_member pathlink.com> writes:
In article <dn2aqq$287q$1 digitaldaemon.com>, AjO says...

In article <dn29eo$26d2$1 digitaldaemon.com>, Kramer says...

Also, 'final' I'm guessing would remove the need for methods to be virtual, thus
potentially speeding up those methods, no?

-Kramer


Well, it says in the D spec that there is no virtual table. Or that's what it
says at: http://www.digitalmars.com/d/module.html


I was thinking of it in regards to class methods since I thought I saw somewhere
in the docs that by default, they would be virtual.  Although I can't find it at
the moment... argh... :<

-Kramer
Dec 05 2005
prev sibling parent Dave <Dave_member pathlink.com> writes:
In article <dn2aqq$287q$1 digitaldaemon.com>, AjO says...

In article <dn29eo$26d2$1 digitaldaemon.com>, Kramer says...

Also, 'final' I'm guessing would remove the need for methods to be virtual, thus
potentially speeding up those methods, no?

-Kramer


Well, it says in the D spec that there is no virtual table. Or that's what it
says at: http://www.digitalmars.com/d/module.html


That page is for modules, not classes. For classes, all non-private, non-package
and non-final methods are vtabled.

I think the docs need to be expanded on what attributes are supposed to do for
class definitions as opposed to class members - "private class" for example is
allowed by the compiler, but apparently doesn't do anything; you can still new a
private class in another module for example.

'final class' however does seem to effect just the member functions, marking
them final as you mentioned earlier.
Dec 05 2005
prev sibling parent reply AjO <AjO_member pathlink.com> writes:
True. I was not complaining though ;) Just pointing out the function of the
'final' keyword. Actually I like it this way, because the behaviour found in
Java seems somewhat artificial to me. After all, inheritance from multiple
"physical" classes is not possible; you can have only one "physical" base class

functionality needed for modern OOP, I'd give my votes for not even implementing
final classes the way Java does. All I want to do is protect my implementation
from tampering. In a certain way my implementation also "persists", because you
cannot override those methods.
To summarize, I can think of a few uses for this. Loud "NO" to Java-ish final
classes.

In article <a8deea61394d8c7c7b84971d1f0 news.digitalmars.com>, Chris Lajoie
says...


find out that the StringBuilder class was marked 'sealed' (aka 'final'). 
All I wanted to do was extend it's functionality, I didn't want to override 
its methods. I don't see any reason why it shouldn't be possible, since the 
purpose of marking a class final is to prevent tampering with its
implimentation. 
It may well be a bug though, since it is clear from your code that you don't 
want anyone to be able to subclass it, regardless of whether people find 
it irritating.

Chris


 Hello everyone!
 
 I was today looking into the similarities/differences of Java and D. I
 experimented with the 'final' keyword. In Java, when used with class
 declaration, guarantees that one cannot subclass from a 'final' class.
 Now, I tried the similar approach in D, and to my surprise, noticed
 that with the code provided below, only the methods become final. This
 means that I can subclass a 'final' class in D with no problem. All I
 can't do is override the methods in that 'final' class. Is this
 desired behaviour, or is the something wrong with my snippet?
 
 import std.stdio;
 
 final class Kid
 {
 void a()
 {
 writefln("a() in Kid");
 }
 void b()
 {
 writefln("b() in Kid");
 }
 }
 class Youngster : Kid
 {
 /*
 void a()
 {
 // Uncommenting causes a compiler error.
 }
 */
 void c()
 {
 a();
 }
 void d()
 {
 b();
 }
 }
 int main(char[][] argumentTable)
 {
 Kid k = new Kid();
 k.a();
 k.b();
 Youngster g = new Youngster();
 
 g.a();
 g.b();
 g.c();
 g.d();
 return 0;
 }
Dec 05 2005
parent reply Stefan Zobel <Stefan_member pathlink.com> writes:
In article <dn29he$26jp$1 digitaldaemon.com>, AjO says...

All I want to do is protect my implementation
from tampering. In a certain way my implementation also "persists", because you
cannot override those methods.
To summarize, I can think of a few uses for this. Loud "NO" to Java-ish final
classes.


You CAN access private members (methods and data) that way.
I wouldn't call this "protection of implementation". Perhaps the
Java way is better in this respect, no?

Best regards,
Stefan
Dec 05 2005
next sibling parent Stefan Zobel <Stefan_member pathlink.com> writes:
In article <dn2ar9$2887$1 digitaldaemon.com>, Stefan Zobel says...

In article <dn29he$26jp$1 digitaldaemon.com>, AjO says...

All I want to do is protect my implementation
from tampering. In a certain way my implementation also "persists", because you
cannot override those methods.
To summarize, I can think of a few uses for this. Loud "NO" to Java-ish final
classes.


You CAN access private members (methods and data) that way.
I wouldn't call this "protection of implementation". Perhaps the
Java way is better in this respect, no?


Tough, this actually has nothing to do with the "final" keyword.

Stefan
Dec 05 2005
prev sibling next sibling parent AjO <AjO_member pathlink.com> writes:
You CAN access private members (methods and data) that way.
I wouldn't call this "protection of implementation". Perhaps the
Java way is better in this respect, no?

Best regards,
Stefan


Thanks for reminding me Stefan :) There are indeed some issues to consider in
this approach. I have to admit that the Java way is slightly better in the
respect you mentioned. Still, do remember that you can always 'final' your data
as well. But this is rather strange considering that I'm just trying to protect
my implementation. If you take a look at my code snippet, it's just a normal
inheritance where the usual measures must be taken to govern the access to the
data. 
Yet, if there was such a thing as final classes in D, we could circumvent the
usual problems by using composition instead of inheritance. However, I still
maintain my opinion that the way things work now are just fine.
Dec 05 2005
prev sibling parent Stefan Zobel <Stefan_member pathlink.com> writes:
In article <dn2ar9$2887$1 digitaldaemon.com>, Stefan Zobel says...

In article <dn29he$26jp$1 digitaldaemon.com>, AjO says...

All I want to do is protect my implementation
from tampering. In a certain way my implementation also "persists", because you
cannot override those methods.
To summarize, I can think of a few uses for this. Loud "NO" to Java-ish final
classes.


You CAN access private members (methods and data) that way.
I wouldn't call this "protection of implementation". Perhaps the
Java way is better in this respect, no?


Stupid me! That's only if they are in the same file, of course.
I should think before writing ...

Sorry,
Stefan
Dec 05 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 5 Dec 2005 20:11:15 +0000 (UTC), AjO wrote:


 Hello everyone!
 
 I was today looking into the similarities/differences of Java and D. I
 experimented with the 'final' keyword. In Java, when used with class
 declaration, guarantees that one cannot subclass from a 'final' class. Now, I
 tried the similar approach in D, and to my surprise, noticed that with the code
 provided below, only the methods become final. This means that I can subclass a
 'final' class in D with no problem. All I can't do is override the methods in
 that 'final' class. Is this desired behaviour, or is the something wrong with
my
 snippet?


No, there is no error in your code. 'final' and 'private' apply to
functions and not classes. There is no such thing as a final class or a
private class in D. There are classes that can contain final functions
and/or private functions.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"A learning experience is one of those things that says,
 'You know that thing you just did? Don't do that.'" - D.N. Adams
6/12/2005 11:54:18 AM
Dec 05 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1w14cf2n0yaen$.1fya63bj3ql24$.dlg 40tude.net...

 There is no such thing as a final class or a
 private class in D.


I really wish there were private classes..
Dec 05 2005
parent reply "Kris" <fu bar.com> writes:
There are. You make the ctor private.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:dn2o4p$2loa$1 digitaldaemon.com...

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1w14cf2n0yaen$.1fya63bj3ql24$.dlg 40tude.net...

 There is no such thing as a final class or a
 private class in D.


 I really wish there were private classes..
Dec 05 2005
next sibling parent Tom <Tom_member pathlink.com> writes:
Not much of a private if you ask me. IMO private means invisibility and not
"uninstantiability". So the symbol must NOT be viewable by the outside user of
the module.

Tom

PS: Not my intention to restart an old discussion, but private (at module level)
should mean invisible.

In article <dn2o7c$2lu2$1 digitaldaemon.com>, Kris says...

There are. You make the ctor private.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:dn2o4p$2loa$1 digitaldaemon.com...

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1w14cf2n0yaen$.1fya63bj3ql24$.dlg 40tude.net...

 There is no such thing as a final class or a
 private class in D.


 I really wish there were private classes..
Dec 05 2005
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Doesn't work.  Classes with private ctors can still be constructed.  I 
think ctors are always implicitly public in D.

Kris wrote:

 There are. You make the ctor private.
 
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:dn2o4p$2loa$1 digitaldaemon.com...

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1w14cf2n0yaen$.1fya63bj3ql24$.dlg 40tude.net...

 There is no such thing as a final class or a
 private class in D.


 I really wish there were private classes..
Dec 05 2005
parent reply "Kris" <fu bar.com> writes:
That's a bug, then.

I've recently noticed private doesn't make a darned bit of difference, 
regardless of what one applies it to. This was not always the case ~ private 
used to actually do "something" :-)


"Sean Kelly" <sean f4.ca> wrote in message 
news:dn33tc$2uqa$2 digitaldaemon.com...

 Doesn't work.  Classes with private ctors can still be constructed.  I 
 think ctors are always implicitly public in D.

 Kris wrote:

 There are. You make the ctor private.

 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:dn2o4p$2loa$1 digitaldaemon.com...

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1w14cf2n0yaen$.1fya63bj3ql24$.dlg 40tude.net...

 There is no such thing as a final class or a
 private class in D.


 I really wish there were private classes..
Dec 05 2005
parent reply "Kris" <fu bar.com> writes:
Jumped the gun a bit:

=================
module B;

class B
{
        private this() {}
        private void bar() {}
}

struct X
{
        private static final void error() {}
}

=================

module A;

import B;

void main()
{
        X x;

        X.error();              // bug! can see X.error
        x.error();               // cannot see x.error
        auto b = new B;    // cannot see ctor
        b.bar();                 // cannot see method
}

==================

There's just the one case above that fails ~ I've being writing a lot of 
structs lately. I guess that's a bug?

- Kris


"Kris" <fu bar.com> wrote in message news:dn359j$30lp$1 digitaldaemon.com...

 That's a bug, then.

 I've recently noticed private doesn't make a darned bit of difference, 
 regardless of what one applies it to. This was not always the case ~ 
 private used to actually do "something" :-)


 "Sean Kelly" <sean f4.ca> wrote in message 
 news:dn33tc$2uqa$2 digitaldaemon.com...

 Doesn't work.  Classes with private ctors can still be constructed.  I 
 think ctors are always implicitly public in D.

 Kris wrote:

 There are. You make the ctor private.

 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:dn2o4p$2loa$1 digitaldaemon.com...

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1w14cf2n0yaen$.1fya63bj3ql24$.dlg 40tude.net...

 There is no such thing as a final class or a
 private class in D.


 I really wish there were private classes..
Dec 05 2005
parent Sean Kelly <sean f4.ca> writes:
Kris wrote:

 Jumped the gun a bit:
 
 =================
 module B;
 
 class B
 {
         private this() {}
         private void bar() {}
 }
 
 struct X
 {
         private static final void error() {}
 }
 
 =================
 
 module A;
 
 import B;
 
 void main()
 {
         X x;
 
         X.error();              // bug! can see X.error
         x.error();               // cannot see x.error
         auto b = new B;    // cannot see ctor


Nice.  This has changed since I last tested it then.


         b.bar();                 // cannot see method
 }
 
 ==================
 
 There's just the one case above that fails ~ I've being writing a lot of 
 structs lately. I guess that's a bug?


Looks like it.  And as a side-note, private template members are not 
visible at module scope.  This one drives me a bit crazy from time to 
time :-)


Sean
Dec 05 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Kris wrote:

 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:dn2o4p$2loa$1 digitaldaemon.com...
 

"Derek Parnell" <derek psych.ward> wrote in message 
news:1w14cf2n0yaen$.1fya63bj3ql24$.dlg 40tude.net...


There is no such thing as a final class or a
private class in D.


I really wish there were private classes..


 
 There are. You make the ctor private.
 


Not a good solution. Conceptually, protection attributes should work the 
same for all named entities. (And things not being so, there are indeed 
practical problems that that solution does not solve.)


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Dec 06 2005
next sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Bruno Medeiros wrote:

 Not a good solution. 


Correction, I meant: "Not a proper solution, just a workaround."


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Dec 06 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 06 Dec 2005 21:34:59 +0000, Bruno Medeiros  
<daiphoenixNO SPAMlycos.com> wrote:

 Kris wrote:

 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message  
 news:dn2o4p$2loa$1 digitaldaemon.com...


 "Derek Parnell" <derek psych.ward> wrote in message  
 news:1w14cf2n0yaen$.1fya63bj3ql24$.dlg 40tude.net...


 There is no such thing as a final class or a
 private class in D.


 I really wish there were private classes..


  There are. You make the ctor private.


 Not a good solution. Conceptually, protection attributes should work the  
 same for all named entities.


While I agree with you...

<stop reading here unless you're interested in a little hair splitting>

I want to point out that I believe there is a conceptual difference  
between these:

int a;
class a {}

in the first an instance of an 'int' is created/requested. In the second a  
type 'a' is defined, but no instance is created/requested.

D seems to me to apply protection attributes to instances or parts of  
instances, eg.

class a {
   private int b;
}

but not to type definitions, eg.

private class a {}
private struct b {}
private typedef int mytype;
private alias int myalias;

Depending on your definition of "private" it's current behaviour can make  
perfect sense. Eg. "private" is an _access_ specifier it prevents _access_  
to a <thing>, as a class definition is not accessed (as in, accessed in  
memory) thus private has no effect on it.

Compare "private" to "static" in C. Despite the documentation saying so,  
private is not the same as the "static" keyword in C. "static" in C  
prevents visibility, which in turn prevents access. "private" only  
prevents access, currently.

My impression is that most people would like "private" to treat instance  
and declarations the same. In most cases the desire is to prevent  
namespace pollution and/or to hide internal workings of something, which  
seems like a good idea to me. I can't really see the benefit in the  
current behaviour.

Regan
Dec 06 2005
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:ops1dt67cg23k2f5 nrage.netwin.co.nz...

 My impression is that most people would like "private" to treat instance 
 and declarations the same. In most cases the desire is to prevent 
 namespace pollution and/or to hide internal workings of something, which 
 seems like a good idea to me. I can't really see the benefit in the 
 current behaviour.


Yeah, that's pretty much it.  I want to be able to keep certain things local 
to a module and not visible in any way to any other modules.  I think 
"private" fits the bill pretty well there.
Dec 06 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Regan Heath wrote:

 My impression is that most people would like "private" to treat 
 instance  and declarations the same. In most cases the desire is to 
 prevent  namespace pollution and/or to hide internal workings of 
 something, which  seems like a good idea to me. I can't really see the 
 benefit in the  current behaviour.
 


"instance and declarations" is actually a misnomer (since "instance" 
like "int num;" is also a declaration), but I understand what you meant.
And yes, like I said before, I think protection should work the same for 
all entities, whether they are runtime entities or compiletime-only 
entities.


 Compare "private" to "static" in C. Despite the documentation saying
 so,  private is not the same as the "static" keyword in C. "static" in
 C  prevents visibility, which in turn prevents access. "private" only
 prevents access, currently.


Yes, I understand the difference, I had read your talk about this 
before. This is a different issue that before, note, and here I'm not 
sure I agree with you. What's the difference to the programmer between:
   Error: foo.bar is not accessible.
and
   Error: foo.bar identifier not found.
?
I see no problem with the first case. Remember that protection 
attributes are not made for some sort of code security, permission or 
secrecy, they are meant simply for code conceptual abstraction.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Dec 07 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 07 Dec 2005 23:11:06 +0000, Bruno Medeiros  
<daiphoenixNO SPAMlycos.com> wrote:

 Regan Heath wrote:

 My impression is that most people would like "private" to treat  
 instance  and declarations the same. In most cases the desire is to  
 prevent  namespace pollution and/or to hide internal workings of  
 something, which  seems like a good idea to me. I can't really see the  
 benefit in the  current behaviour.


 "instance and declarations" is actually a misnomer (since "instance"  
 like "int num;" is also a declaration), but I understand what you meant.


Indeed, I may have picked the wrong words to describe what I mean. For  
example "defintion" seems better than "declaration", so...

"instance"   - an "entity" that "exists" in memory at runtime.
"definition" - layout of an entity, this layout never "exists" as an  
"entity" itself.


 And yes, like I said before, I think protection should work the same for  
 all entities, whether they are runtime entities or compiletime-only  
 entities.


My point was that a definition is not an "entity", it never "exists" in  
memory, instead instances are built in the layout it describes. As  
definitions never exist they need not be protected (assuming your  
definition of protection applies only to entities that exist at runtime,  
for example)

I'm splitting hairs again, because I enjoy this sort of discussion.  
Practically, I think we should be able to stop people using a definition.  
I don't have a strong opinion as to what keyword to use for it. It seems  
many people expect "private" to do it, so that may be a good choice.


  > Compare "private" to "static" in C. Despite the documentation saying
  > so,  private is not the same as the "static" keyword in C. "static" in
  > C  prevents visibility, which in turn prevents access. "private" only
  > prevents access, currently.
  >

 Yes, I understand the difference, I had read your talk about this  
 before. This is a different issue that before, note, and here I'm not  
 sure I agree with you. What's the difference to the programmer between:
    Error: foo.bar is not accessible.
 and
    Error: foo.bar identifier not found.
 ?


The first says to me:
"I know what and where foo.bar is, but I'm not going to let you access it".

The second says to me:
"I have no idea what or where foo.bar is".

Practically there is little difference between them, they both prevent the  
programmer from using foo.bar. However the first error message is more  
specific, it tells you exactly what the problem is. The latter is less  
specific, it could be a number of things, typo, incorrect linkage, missing  
source file, ...

I think we all prefer specific error messages to vague ones. :)


 I see no problem with the first case. Remember that protection  
 attributes are not made for some sort of code security, permission or  
 secrecy, they are meant simply for code conceptual abstraction.


Sure, I agree. I see no reason to use less specific errors where we can be  
nice and specific. However, the price for being specific is that the  
symbol is always exported, what I mean is that...

In the case of static the C compiler does not export the symbol from the  
source file, this means that when compiling another file which references  
the symbol you get an error like the second one above.

In the case of D's protection, the compiler always exports the symbol even  
if it's private, this allows it to give the more specific error, the first  
error above.

By "export" above I mean simply that the compiler knows about a variable  
 from "foo" when it is compiling a different module ie. "bar". Now, I'm not  
a compiler writer so I'm mostly guessing but doesn't this mean that the  
symbol must exist in foo.o? that it is always exported? even though it is  
private? (and actually inaccessable from anywhere outside "foo")

It seems to me that a private symbol is exported simply to give the  
specific error above, I find this interesting and it leads me to a new  
question: Does anyone have the need to actually prevent a symbol from  
being exported?

Regan
Dec 07 2005