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-bugs
mailing list