Multiple attribute specifiers

Ary Manzana asterite at gmail.com
Fri Sep 8 05:11:27 PDT 2006


Steve Horne wrote:
> On Thu, 07 Sep 2006 19:31:01 +0100, Stewart Gordon
> <smjg_1998 at yahoo.com> wrote:
> 
>> Can you remember anything at all about this post?  Such as who wrote it, 
>> or enough words from the subject line or body that there is some hope of 
>> finding it?
> 
> The relevant bits from the original post, reposted and crossposted...
> 
> : I'd guess it falls out of allowing several access modifier styles...
> : 
> : class xxx
> : {
> :   public:
> :     private int x;
> : }
> : 
> : This makes sense. The C++-like colon can be seen as changing a default
> : that runs on until the next access modifier. The Java-like variant is
> : more convenient for a this-declaration-only access modifier. With the
> : block version supported as well, it's obviously mainly about keeping
> : C++ and Java programmers happy, but there is a logic to layering
> : access modifiers.
> : 
> : In the compiler, it's probably easier to handle that as 'the last
> : modifier is the real one' than to sort out different cases, and have
> : more specific rules.
> : 
> : Also, the grammar probably just allows modifiers to be added to
> : declarations arbitrarily. Should 'private' go before or after
> : 'static'? Why not allow both cases. But the easiest way to allow both
> : cases will also allow two access modifiers, or two storage modifiers.
> : 
> : After all, the following compiles fine too...
> : 
> :   static static int m_Var;
> : 
> : No contradiction in that, of course, but still pretty wierd.
> : 
> : The question is... is this really a problem?
> 

I finally think it's not a big deal, it just that in any other language 
I find the compiler complaining about these stuff, just to make sure the 
programmer doesn't accidentally put a private where a public was there 
and vice versa.

Also, I found a new one:

--------------------------
final abstract class Bla {
}
--------------------------

Again, compiles perfectly, but why should want such a code to compile?

Java doesn't allow all of these and, just as an example, it doesn't 
allow catching non-runtime exceptions that are never thrown (I'm not 
saying D should behave that way). Why? Just to make the code as clear as 
possible, without letting you say redundant or unnecessary things.

Anyway, I think that, if we consider this a problem, it has a very low 
priority.

Ary



More information about the Digitalmars-d-learn mailing list