Huh, invariant() {...} ?

Henning Hasemann hhasemann at web.de
Mon Jun 18 14:32:46 PDT 2007


Am Mon, 18 Jun 2007 22:08:47 +0300
schrieb "Kristian Kilpi" <kjkilpi at gmail.com>:

> Too much keywords in a language is not good, but maybe a new keyword
> (e.g. 'classinvariant') for the class invariants would be justified.
> Semantic ambiguity is not nice either.

I think that is a common mistake. Maybe too many different *meanings*
or techniques or whatever in a language are not good.
I cant imagine why it should be better to have very few keywords with
each relatively much different meanings than more with each a unique or
just few meanings considering ease of coding and understanding written
code.

The only argument against new keywords for new compiler-features that
can not be expressed as library functions is, that they might pollute
different namespaces such as the one for modules or variable names.

But maybe the right approach then is not to reduce the number of
keywords but build up a syntax that makes it always possible to
distinguish a user-defined name from a keyword.

For example in

const invariant int const;

its clear that the last const would be the variable name even it is a
keyword too. I agree that this is *pretty* ugly, but I recently wanted
to create a module that defines the base class for all possible
interfaces (ie user interfaces) to my program. Naming it "interface"
was a bad idea. I came up very quickly with "ui" but there may be
situations where it is not that easy to find a pleasant name.
(Names *are* important!)

So for a summary: I dont expect to find such an idea in a D release that
comes out this decade, I'm just "thinking around", maybe someone has
some interesting comments / ideas on this?!

Henning

-- 
GPG Public Key:
http://keyserver.ganneff.de:11371/pks/lookup?op=get&search=0xDDD6D36D41911851
Fingerprint: 344F 4072 F038 BB9E B35D  E6AB DDD6 D36D 4191 1851



More information about the Digitalmars-d mailing list