"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a5lnc5$26sv$1@digitaldaemon.com...

> I might 'label' my functions too:
>
> ODDPrint();
> ODDOpenTable();
> ODDAnotherFunc()
>
> OpenGL uses something like it:
>
> glBegin();
> gluLookAt();
> glutBlahBlah();
>
> where glu and glut are libraries that extend OpenGL.
>
> I don't like it though....

"Labeling" is used to avoid name clashes - which no longer happens since D has modules.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a5loj7$27hp$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a5lnc5$26sv$1@digitaldaemon.com...
>
> > I might 'label' my functions too:
> >
> > ODDPrint();
> > ODDOpenTable();
> > ODDAnotherFunc()
> >
> > OpenGL uses something like it:
> >
> > glBegin();
> > gluLookAt();
> > glutBlahBlah();
> >
> > where glu and glut are libraries that extend OpenGL.
> >
> > I don't like it though....
>
> "Labeling" is used to avoid name clashes - which no longer happens since D has modules.
>

Ah yes ofcourse, I hadn't thought of that...So that is why
they did that! Microsoft didn't bother though...Luckily
for us:

MSCreateWindowEx();
MSMessageBox();

Imagine that? I really get annoyed of all the MS's now, also in their filenames...


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

Richard Krehbiel a écrit :

> D is case-sensitive because C is, right?  Is that a good enough reason?
>
> I've read a few flame-fests on comp.lang.c that, um, "discussed" this issue, and I've never seen any authoritative word stating why case-sensitivity is better - and I have my own catalog of personal experiences saying why it's worse.
>
> Why can't D be case-insensitive?
>

One of the bigger bug i ever had:

class Arc: public Something {    //note the case of Arc
.
    virtual int id()const {
        return A_VALUE;
    }
.
};

somewhere else, written by somebody else, in an other library:

class ARC: public SomethingElse {    //note the case of ARC
.
    virtual int id()const {
        return AN_OTHER_VALUE;
    }
.
};

Unfortunately the linker or the librarian was not configured to be case
sensitive.
So the linker took the first one it found and throw away the other one.
You can guess the problem..

To avoid that, the compiler, the linker and the librarian _must_ _all_ be case
sensitive.
In that case, one of the 3 would have complained.

More generaly:

I think name convention is important.
Microsoft know that when they almost force there developpers to use ugrarian
convention.
Too much i think in a strong typed langage like C.
HP developpers didn't care at all when they created STL: STL type names are
really names i could have used
(and used) for local data names.

At the beginning of D, i hesitateted to send a post sugesting that D _force_
name standardization.
Here what i was about to suggest:
- arguments or local data name: should start with a isalpha letter (not
underscore) and be _all_ low case,
- data/function name: the first isalpha letter should be low case,
- #defines: _all_ isalpha letters should be UPPER case,
- Type names: first isalpha letter should be UPPER case

next cannot be forced by the compiler (waiting for compiler using AI):

- the more the name is global (#defines, Type name, global data/function name),
the longuer and explicit it should be,
- at the contrary, statics function/data, local data or arguments names can be
very short,
- leading underscore: generaly, exept for local data or arguments name,
underscore indicates the 'depth in privacy' of the name,
that mean if it is here for the "user" (the one who will use what you
implemented), or just to help implementation.
In that case, the name should begin with at least one underscore.

Having a case sensitive langage can help force standadization i think.

roland

"Roland" <rv@ronetech.com> wrote in message news:3C7FC3AE.4AD224B@ronetech.com...

> At the beginning of D, i hesitateted to send a post sugesting that D
_force_
> name standardization.
> Here what i was about to suggest:
> - arguments or local data name: should start with a isalpha letter (not
> underscore) and be _all_ low case,

I don't think it's a good idea to define some strict rules for locals. They're implementation detail, after all. Better focus on the interface.

> - data/function name: the first isalpha letter should be low case, - #defines: _all_ isalpha letters should be UPPER case,

You mean consts/enums? Then, I don't agree. Personally, I hate this C tradition of writing all constants in upper case. I prefer to name consts in the same way as variables, and capitalize first letter of each word of enum member.

Anyhow, I don't think it's the best idea. Walter had specified a recommendation that most people will follow (I hope =)). But some companies prefer to develop their own schemas for internal use, why not let them do so?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a5omjt$lkl$1@digitaldaemon.com...

> Anyhow, I don't think it's the best idea. Walter had specified a recommendation that most people will follow (I hope =)). But some companies prefer to develop their own schemas for internal use, why not let them do so?

   Some languages use naming schemes to help with parsing, and to eliminate
clutter from the language. Take Haskell, for example:

- ident beginning with lowercase: functions and variables.
- ident beginning with uppercase: types and type constructors
- Symbols: operators
- Symbols in parens: operators being used as functions

   It helps them remove the need for extra symbols (parenthesis and commas
for parameters, for example).

   It is definitely not the C/C++ way, though.

Salutaciones,
                         JCAB