www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - base class access specifier[s]

reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Tee hee. I can make the compiler swallow something silly:

module silly;

interface I{
	void foo();
}

class C: public private protected package protected public protected 
public private protected package I{
	void foo(){}
}

void main(){}
Jan 18 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Ellery,


 Tee hee. I can make the compiler swallow something silly:
 
 module silly;
 
 interface I{
 void foo();
 }
 class C: public private protected package protected public protected
 public private protected package I{
 void foo(){}
 }
 void main(){}
 


Um. OK. It turns out it's easier to make the compiler eat that than it is 
to make it reject it. Also sometimes it's handy to have it look at only the 
last cases (I think that's what it does). As an example, in generated code. 
Another example of this is in unix command line apps that often have on/off 
flag pairs that can be mixed ad-nauseum because they grab flags from several 
different sources that need to override each other.
Jan 18 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
BCS wrote:

 Hello Ellery,
 

 Tee hee. I can make the compiler swallow something silly:

 module silly;

 interface I{
 void foo();
 }
 class C: public private protected package protected public protected
 public private protected package I{
 void foo(){}
 }
 void main(){}


 
 Um. OK. It turns out it's easier to make the compiler eat that than it 
 is to make it reject it. Also sometimes it's handy to have it look at 
 only the last cases (I think that's what it does). As an example, in 
 generated code. Another example of this is in unix command line apps 
 that often have on/off flag pairs that can be mixed ad-nauseum because 
 they grab flags from several different sources that need to override 
 each other.
 
 


I don't buy that. Not that I'm a C guru or anything, but it looks to me 
that Parser::BaseClasses could be easily edited to make the point in 
question go away.
Also, I don't quite follow your rationale, but I'll accept it just the 
same. I like this feature :D
Jan 19 2009
parent reply BCS <ao pathlink.com> writes:
Reply to Ellery,


 I don't buy that. Not that I'm a C guru or anything, but it looks to
 me that Parser::BaseClasses could be easily edited to make the point
 in question go away.
 


it's not a parser thing but a grammar thing. It would be complex to define 
a grammar that allows one each of the different types of prefixes that are 
allowed:

int a = 5;
auto b = 5;
const c = 5;
static d = 5;
const static int e = 5;
protected const static int f = 5;
static const protected g = 5;

each of those is allow and reasonable in different contexts. To avoid redundant 
grammars and inconsistencies they are generalized and also shared with classes, 
structs, etc.
Jan 19 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
BCS wrote:

 Reply to Ellery,
 

 I don't buy that. Not that I'm a C guru or anything, but it looks to
 me that Parser::BaseClasses could be easily edited to make the point
 in question go away.


 
 it's not a parser thing but a grammar thing. It would be complex to 
 define a grammar that allows one each of the different types of prefixes 
 that are allowed:
 
 int a = 5;
 auto b = 5;
 const c = 5;
 static d = 5;
 const static int e = 5;
 protected const static int f = 5;
 static const protected g = 5;
 
 each of those is allow and reasonable in different contexts. To avoid 
 redundant grammars and inconsistencies they are generalized and also 
 shared with classes, structs, etc.
 
 


I don't buy that either. The subject was access specifiers for base 
classes, not storage classes for declarations or access specifiers for 
statements. In those cases I would grant your point, but a base class 
has precisely one access specifier and no storage classes. It would not 
be complex to define such a grammar and in fact the D grammar does 
precisely this.
Jan 19 2009
next sibling parent BCS <ao pathlink.com> writes:
Reply to Ellery,


 BCS wrote:
 

 Reply to Ellery,
 

 I don't buy that. Not that I'm a C guru or anything, but it looks to
 me that Parser::BaseClasses could be easily edited to make the point
 in question go away.
 


 it's not a parser thing but a grammar thing. It would be complex to
 define a grammar that allows one each of the different types of
 prefixes that are allowed:
 
 int a = 5;
 auto b = 5;
 const c = 5;
 static d = 5;
 const static int e = 5;
 protected const static int f = 5;
 static const protected g = 5;
 each of those is allow and reasonable in different contexts. To avoid
 redundant grammars and inconsistencies they are generalized and also
 shared with classes, structs, etc.
 


 I don't buy that either. The subject was access specifiers for base
 classes, not storage classes for declarations or access specifiers for
 statements. In those cases I would grant your point, but a base class
 has precisely one access specifier and no storage classes. It would
 not be complex to define such a grammar and in fact the D grammar does
 precisely this.
 


OTOH it /would/ be redundant because you would then need to define access 
specifiers independently for class declarations as well as for variable
declarations. 
IIRC, as things stand now the access specifiers are consumed by the grammar 
before it even gets from the generic declarations grammar to the
class/struct/variable 
specialization.

Declaration ::= DeclAnnotation Item
Item ::= ClassDecl | StructDecl | VarDecl | ...
Jan 19 2009
prev sibling parent BCS <ao pathlink.com> writes:
Reply to Ellery,


 I don't buy that either. The subject was access specifiers for base
 classes, not storage classes for declarations or access specifiers for
 statements. In those cases I would grant your point, but a base class
 has precisely one access specifier and no storage classes. It would
 not be complex to define such a grammar and in fact the D grammar does
 precisely this.
 


another reason: to avoid this requiters more look ahead
Jan 19 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Ellery Newcomer wrote:

 Tee hee. I can make the compiler swallow something silly:
 
 module silly;
 
 interface I{
     void foo();
 }
 
 class C: public private protected package protected public protected 
 public private protected package I{
     void foo(){}
 }
 
 void main(){}


Also, access specifiers on inherited or implemented base types aren't 
honored:
class C : private I {}

C is still implicitly convertible to I.
Jan 19 2009