What about namespaces ?

[Rui Maciel]

When a C program grows, the odds that two identifier names will clash will
increase. So, unless the programmer has in place an effective policy to
name every identifier that is able to avoid any naming clash, including
thosed introduced by third-party code, the odds that this problem will
manifest itself will also become greater.

This problem isn't particularly hard to avoid. A simple policy based on
adding a descriptive prefix to the identifier name tends to be enough for
most cases. Even in corner cases, such as possible name clashes between
incompatible versions of the same library, it is possible to sidestep this
by adding a reference to the library version to the prefix being used.

Nonetheless, by relying on this method, identifier names tend to become a
bit verbose. This, in itself, isn't a major problem, but it isn't very
helpful either. After all, it tends to be preferable if it's possible to
call a function named do_stuff() instead of being forced to call another one
named package_name_version_library_task_do_stuff(), and long identifier
names tend to make some code constructs a bit hard to read.

A possible way to cut on verbose identifier names would be to implement a
system where these prefixes could be left implied by the programmer in such
a way that, in a given context, a call to do_stuff() could unambiguously be
interpreted as a call to package_name_version_library_task_do_stuff(). This
could, hypothetically, be accomplished by letting programmers specify
exactly, both in declarations and definitions, which group of identifiers
would share a specific naming prefix, and then also specify in which block
these naming prefixes could be left implied.

What I've described is, in essence, the concept of namespaces, which has
been a part of other programming languages, such as C++, for a long time
now.

So, with this in mind, what are your thoughts on the idea of introducing
namespaces to the C programming language? Would it be a bad idea?


Rui Maciel

 

[BartC]

This problem isn't particularly hard to avoid. A simple policy based on
adding a descriptive prefix to the identifier name tends to be enough for
most cases. ....
So, with this in mind, what are your thoughts on the idea of introducing
namespaces to the C programming language? Would it be a bad idea?

Does it really need anything more than allowing "##" (or equivalent) to be
used outside of macros? Then it is possible to replace a long prefix with a
short one. It will do roughly the same job as "::" or ".".

 

[Ian Collins]

Does it really need anything more than allowing "##" (or equivalent) to be
used outside of macros? Then it is possible to replace a long prefix with a
short one. It will do roughly the same job as "::" or ".".

Namespaces (in the C++ sense) need a lot more. A C++ namespace is a
scope, not just a text prefix. So adding them to C would require at
lest one (and probably two with "using") new keywords, basic name
mangling and significant parser changes. All most unlikely.

 

[BartC]

Namespaces (in the C++ sense) need a lot more. A C++ namespace is a
scope, not just a text prefix. So adding them to C would require at lest
one (and probably two with "using") new keywords, basic name mangling and
significant parser changes. All most unlikely.

That's why a simple solution, to shorten the otherwise unwieldy names that
can result from not having namespaces, might be more useful than doing
nothing.

 

[88888 Dihedral]

Rui Macielæ–¼ 2012å¹´4月3日星期二UTC+8下åˆ5時25分10秒寫é“：

When a C program grows, the odds that two identifier names will clash will
increase. So, unless the programmer has in place an effective policy to
name every identifier that is able to avoid any naming clash, including
thosed introduced by third-party code, the odds that this problem will
manifest itself will also become greater.

This problem isn't particularly hard to avoid. A simple policy based on
adding a descriptive prefix to the identifier name tends to be enough for
most cases. Even in corner cases, such as possible name clashes between
incompatible versions of the same library, it is possible to sidestep this
by adding a reference to the library version to the prefix being used.

Nonetheless, by relying on this method, identifier names tend to become a
bit verbose. This, in itself, isn't a major problem, but it isn't very
helpful either. After all, it tends to be preferable if it's possible to
call a function named do_stuff() instead of being forced to call another one
named package_name_version_library_task_do_stuff(), and long identifier
names tend to make some code constructs a bit hard to read.

A possible way to cut on verbose identifier names would be to implement a
system where these prefixes could be left implied by the programmer in such
a way that, in a given context, a call to do_stuff() could unambiguously be
interpreted as a call to package_name_version_library_task_do_stuff(). This
could, hypothetically, be accomplished by letting programmers specify
exactly, both in declarations and definitions, which group of identifiers
would share a specific naming prefix, and then also specify in which block
these naming prefixes could be left implied.

What I've described is, in essence, the concept of namespaces, which has
been a part of other programming languages, such as C++, for a long time
now.

So, with this in mind, what are your thoughts on the idea of introducing
namespaces to the C programming language? Would it be a bad idea?


Rui Maciel

I think one has to declare static variables in the file scope for those
not to be exported and a package header for all extern variables in one's
organization of c files can remedy the problem.

 

[Rui Maciel]

In what way would that be an improvement over "Use C++"?

I see little point in gradually adding features to C to
try to turn it into C++, or a poor version of it.

Just because C++ has namespaces it doesn't mean that this is an attempt to
turn C into C++, or into any other language for that matter. If that was
the case, the addition of range-based for loops to the C++ programming
language would also imply that the C++ people were trying to turn C++ into
Java.

Namespaces can correspond to nothing more than syntactic sugar which happens
to be considerably useful. It doesn't make sense to snub any feature, no
matter how useful it might be, just because some other language already has
it.


Rui Maciel

 

[Rui Maciel]

In what way would that be an improvement over "Use C++"?

I see little point in gradually adding features to C to
try to turn it into C++, or a poor version of it.

Just because C++ has namespaces it doesn't mean that this is an attempt to
turn C into C++, or into any other language for that matter. If that was
the case, the addition of range-based for loops to the C++ programming
language would also imply that the C++ people were trying to turn C++ into
Java.

Namespaces can correspond to nothing more than syntactic sugar which happens
to be considerably useful. It doesn't make sense to snub any feature, no
matter how useful it might be, just because some other language already has
it.


Rui Maciel

 

[Rui Maciel]

In what way would that be an improvement over "Use C++"?

I see little point in gradually adding features to C to
try to turn it into C++, or a poor version of it.

Just because C++ has namespaces it doesn't mean that this is an attempt to
turn C into C++, or into any other language for that matter. If that was
the case, the addition of range-based for loops to the C++ programming
language would also imply that the C++ people were trying to turn C++ into
Java.

Namespaces can correspond to nothing more than syntactic sugar which happens
to be considerably useful. It doesn't make sense to snub any feature, no
matter how useful it might be, just because some other language already has
it.


Rui Maciel

 

[Fritz Wuehler]

When a C program grows, the odds that two identifier names will clash will
increase. So, unless the programmer has in place an effective policy to
name every identifier that is able to avoid any naming clash, including
thosed introduced by third-party code, the odds that this problem will
manifest itself will also become greater.

There is probably no solution to this given the gigantic amount of C library
code that already exists and the unbelievable lack of discipline and "don't
tell me what to do" typical of C programmers as well as the huge number of C
programmers. The linker will probably also have to be changed to support the
weird names, but I am not sure.

What I've described is, in essence, the concept of namespaces, which has
been a part of other programming languages, such as C++, for a long time
now.
Yeah

So, with this in mind, what are your thoughts on the idea of introducing
namespaces to the C programming language? Would it be a bad idea?

Many older languages suffer from this problem and it would be nice to solve
it. I suppose some liberal use of the preprocessor could help here or maybe
writing some m4 scripts. I'm as interested as you to hear if anybody thinks
this will ever fly in the standards committee. Until then if you try rolling
your own you may win and have your idea implemented ;-)

 

[Rui Maciel]

I don't think anyone really likes namespaces as done in C++ (or in
most other implementations). It works, but...

I don't remember ever seeing anyone complain about namespaces in C++, and a
quick google on "C++ namespace criticism" comes up empty. What criticism
are you referring to?

C++-style classes are probably much more useful in that regard.

<snip/>

There is already a C with classes. In fact, there are two of them, or 3 if
you count the D programming language.


Rui Maciel

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×œ×™×©×™, 3 ב×פריל 2012 19:54:21 UTC+1, מ×ת Rui Maciel:

Namespaces can correspond to nothing more than syntactic sugar which happens
to be considerably useful. It doesn't make sense to snub any feature, no
matter how useful it might be, just because some other language already has
it.

You need short identifiers, mu = mean(x, N), not myobject::mean_salary = std::Math.mean(myobject::employees.salary, std::length(myobject::employees));

In a snippet, the long version looks a bit better, since it tells you something. But in real code, if every line is like that, it rapidly becomes unreadable.

I believe in the rule of two. (See my website). Humans like binomial names.That's true in biology, it's true for people's names, it's true for computing as well. So if you call your variable mean-salary, ypu've used up your two names. You can't call it mylib_mean_salary, without violating the rule of two and making people unwilling to use your system.

What we need is a hierarchy. Say you're writing an image library. The user simply wants to call loadimage() and saveimage(). These will intelligently detect the various formats used. However you yourself won't want your jpeg saver in the same file as the gif saver. Lower-lvel functions like savejpeg(), savegif() and the like will exist in separate source files. These symbols shouldn't be visible to anyone who includes "imagelibrary.h".

 

[Keith Thompson]

Does it really need anything more than allowing "##" (or equivalent) to be
used outside of macros? Then it is possible to replace a long prefix with a
short one. It will do roughly the same job as "::" or ".".

Are you suggesting that one could declare something as

foo##bar

and then refer to it either as "foo##bar" or just as "bar"?

 

[Ian Collins]

I don't think anyone really likes namespaces as done in C++ (or in
most other implementations). It works, but...
Eh?

C++-style classes are probably much more useful in that regard. It
effectively does isolate all the class member names behind a prefix
(the class name), and often allows short (unprefixed) access to the
members. In the real world, the number of name clashes per line of
C++ code is vastly lower than for C code. Namespaces work best on top
of that.

There's one big difference between a namespace and a struct/class in
C++: a namespace can be split between multiple files. Otherwise we
could just use a struct to emulate a namespace in C.

 

[Stefan Ram]

So, with this in mind, what are your thoughts on the idea of introducing
namespaces to the C programming language? Would it be a bad idea?

One can collect all names of a library in a struct. The struct is then
published by a pointer. So there only is a single external identifier
necessary per lib, which can be edited in the case of a clash.

 

[Stefan Ram]

I always thought the soluion to that was:
pnvlt_do_stuff()

C89 only had the first six characters being significant in
external identifiers. (And there are reports that C89 still
is widely used today.)

 

[James Kuyper]

C89 only had the first six characters being significant in
external identifiers. (And there are reports that C89 still
is widely used today.)

Only six characters were guaranteed significant in C89, but an
implementation was permitted to use more than just the first six. Do you
have any reports of a C89 implementation, in use today, that treats
fewer than 31 characters as significant? If so, how few does it use?

 

[BartC]

Are you suggesting that one could declare something as

foo##bar

and then refer to it either as "foo##bar" or just as "bar"?

No:

void long_function_prefix_fna(int,int);
void long_function_prefix_fnb(int);
....

define lfp long_function_prefix_

long_function_prefix_fna(10,20); /* long-winded call */
lfp##fna(10,21); /* short call */
lfp::fna(10,22); /* (looks better like this) */

But you can't, in general, just use:

fna(10,23);

Not without defining a macro for each function:

#define fna long_function_prefix_fna

While this is a possibility, and can be done now, it's not as easy
as defining a macro for each library.

 

[Rui Maciel]

There is probably no solution to this given the gigantic amount of C
library code that already exists and the unbelievable lack of discipline
and "don't tell me what to do" typical of C programmers as well as the
huge number of C programmers. The linker will probably also have to be
changed to support the weird names, but I am not sure.

Basically, the only changes which would be required to implement this
feature is how the front-end of a compiler handles identifiers. Let's
consider that all a namespace implementation would do is provide a
programmer with a way to define regions of code where:
- a specific prefix was omitted from declarations and definitions
- prefixes could be left implied in identifiers

With this in mind, consider the following function definition:

<code>
int package_version_do_stuff()
{
return 42;
}
</code>


The previous function definition could be considered equivalent to the
following code:
<code>
namespace package
{
namespace version
{
int do_stuff();
{
return 42;
}
}
}
</code>

Then, whenever any identifier was referenced, the compiler would only need
to check the identifier list to search for any identifier which matched the
identifier string, or any version which included a prefix which has been set
with a "using namespace" directive.

The best part about this way of implementing namespaces in C is that it
would open the door to polymorphism, similar to the one implemented through
the _Generic() keyword in C11. Consider the following example:

<code>
namespace foo
{
namespace int_version
{
void do_stuff(int param)
{
puts("int parameter");
}
}

namespace float_version
{
void do_stuff(float param)
{
puts("float parameter");
}
}
}


int main(void)
{
using namespace foo::int_version, foo_float_version;

do_stuff(1); // this would call foo_int_version_do_stuff(1);

do_stuff(1.0f); // this would call foo_float_version_do_stuff(1);

return 0;
}
</code>



Rui Maciel

 

[jgharston]

What we need is a hierarchy. Say you're writing an image library.
The user simply wants to call loadimage() and saveimage().

The beat them around the head until they want to call image_load()
and image_save() and understand the concept of "hiererchy".

loadimage() is one of a set of load* calls. Things that are to
do with images should be called image*.

Programmer discipline. Naming should be global_local_specific.
acia_int(), acia_test(), acia_send(), acia_read()
image_load(), image_save(), image_jpegtogif(), image_flatten()
skt_open(), skt_close(), skt_send(), skt_read()

See http://www.ganssle.com/articles/namingconventions.htm

Underline namespace is my prefered method, as it clearly identifies
the module and the subfunction (eg net_fsop() vs netfs_op()), but
if you prefer sktopen(), sktclose(), ImageLoad(), ImageSave() they
work as long as you use big-middle-small.

JGH

 

[Rui Maciel]

I always thought the soluion to that was:

pnvlt_do_stuff()

This sort of naming policy has the nasty consequence of leading to
unintelligible names, which in turn leads to unreadable code.

Also, package_name_version_library_task_do_stuff() is much longer than 31
characters. Which begs the question; is 31 characters really too
constraining, or just an annoyance when things break because we didn't put
any subsantial effort into the task at hand.

Maybe the question which should be asked is simply: is that limit really
justified nowadays? Maybe it was practically mandatory in 1972, but things
have progressed a bit since then. Possibly the reason that led to that
limit in 1972 is no longer present in 2011.

I've always considered C's lack of features a kind of "engineer forcing".
Similar to legislative forcing--a term used in American judicial and
political philosophy which implies that, e.g., a court's nullification of
a law is effectively submittal to the legislature to "do it right", as
opposed to a passive constitutional exercise.

In other words, environmental constraints (or stresses, so to speak)
aren't merely meaningless or abstract limits; but ways of saying that, if
you work hard enough to stay within certain bounds, you're more likely to
get it right than under an alternative system; and if we were to loosen
such limits, there would likely be unintended and detrimental
consequences.

I'm not sure I want to live in a software ecosystem where people can run
roughshod over short and sensible identifiers.

This would imply that using short identifier names somehow represents the
right way of doing things, but I don't see how anyone can claim that a piece
of code can improve if someone decides to employ a form of dictionary
compression on the identifier names, or if a function is somehow made worse
if an extra letter is added to its identifier.


Rui Maciel