Has C++ ever considered XML style namespaces?
-
Hello everyone,
I'm sure it's been thought of various times before, but I'm waiting for a rebuild so this is more productive and self-entertaining than staring at the walls...
Just thinking about it without putting any really useful brain cells at risk, it would seem like it would kill two opposing birds with one stone. Lots of people hate having long namespaces used all over the place. Other people say it's a really bad thing because it can lead to clashes down the line and such. But an XML style scheme could work for both.
Any help will be appreciated.
-
Hello everyone,
I'm sure it's been thought of various times before, but I'm waiting for a rebuild so this is more productive and self-entertaining than staring at the walls...
Just thinking about it without putting any really useful brain cells at risk, it would seem like it would kill two opposing birds with one stone. Lots of people hate having long namespaces used all over the place. Other people say it's a really bad thing because it can lead to clashes down the line and such. But an XML style scheme could work for both.
Any help will be appreciated.
Sounds completely pointless. It would be needlessly complicated to solve a non-existent problem.
-
Hello everyone,
I'm sure it's been thought of various times before, but I'm waiting for a rebuild so this is more productive and self-entertaining than staring at the walls...
Just thinking about it without putting any really useful brain cells at risk, it would seem like it would kill two opposing birds with one stone. Lots of people hate having long namespaces used all over the place. Other people say it's a really bad thing because it can lead to clashes down the line and such. But an XML style scheme could work for both.
Any help will be appreciated.
david3217 wrote:
hate having long namespaces
Having to type more is never a good reason to change anything. That's what you have autocompletion for. You should strive to write code that is easy to understand and manage. Writing less is not helping either. Using XML style will make your code harder to read and manage. And if you really can't stand it, C++ already offers
using. E. g. if you do a lot of I/O, you can writeusing std::cout;
using std::endl;
using std::cin;to abbreviate your code in your source file (never in a header file!). Not that it's really neccessary...
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
david3217 wrote:
hate having long namespaces
Having to type more is never a good reason to change anything. That's what you have autocompletion for. You should strive to write code that is easy to understand and manage. Writing less is not helping either. Using XML style will make your code harder to read and manage. And if you really can't stand it, C++ already offers
using. E. g. if you do a lot of I/O, you can writeusing std::cout;
using std::endl;
using std::cin;to abbreviate your code in your source file (never in a header file!). Not that it's really neccessary...
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Quote:
Having to type more is never a good reason to change anything
I disagree (I know, it is a matter of personal taste, anyway). It is not just typing, but also reading back what you have (or some other developer has) typed. Think at progresses made in mathematics with the introduction of the symbolic notation (it is a far fetched example, but it gives you the idea).
-
Quote:
Having to type more is never a good reason to change anything
I disagree (I know, it is a matter of personal taste, anyway). It is not just typing, but also reading back what you have (or some other developer has) typed. Think at progresses made in mathematics with the introduction of the symbolic notation (it is a far fetched example, but it gives you the idea).
If you type more, the resulting text should make your code more readable, not less. If it doesn't, that is an entirely different problem. As a mathematician I do understand the advantage of short notation conventions. However, I also understand the problem of others not understanding your notation if they are not familiar with the shorthand notation you are using. So, if within your project team everyone agrees to certain shorthand notations, and actually take the time to document this (in case new members join the team), then the more power to you. Otherwise, just don't do it!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
If you type more, the resulting text should make your code more readable, not less. If it doesn't, that is an entirely different problem. As a mathematician I do understand the advantage of short notation conventions. However, I also understand the problem of others not understanding your notation if they are not familiar with the shorthand notation you are using. So, if within your project team everyone agrees to certain shorthand notations, and actually take the time to document this (in case new members join the team), then the more power to you. Otherwise, just don't do it!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Quote:
If you type more, the resulting text should make your code more readable, not less
Verbosity does not imply clarity. Often writing less makes your text more readable ("Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte" :-D ).
Quote:
As a mathematician I do understand the advantage of short notation conventions. However, I also understand the problem of others not understanding your notation if they are not familiar with the shorthand notation you are using. So, if within your project team everyone agrees to certain shorthand notations, and actually take the time to document this (in case new members join the team), then the more power to you. Otherwise, just don't do it!
I do agree with you on this (still, I believe that
'i'is a better name than'index'). -
Quote:
If you type more, the resulting text should make your code more readable, not less
Verbosity does not imply clarity. Often writing less makes your text more readable ("Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte" :-D ).
Quote:
As a mathematician I do understand the advantage of short notation conventions. However, I also understand the problem of others not understanding your notation if they are not familiar with the shorthand notation you are using. So, if within your project team everyone agrees to certain shorthand notations, and actually take the time to document this (in case new members join the team), then the more power to you. Otherwise, just don't do it!
I do agree with you on this (still, I believe that
'i'is a better name than'index').CPallini wrote:
still, I believe that
'i'is a better name than'index'It depends... In a very short for loop I usually prefer using 'i'. However, if I fill in some listbox/listcontrol I prefer using 'index' or 'item' rather than 'i'.
-
CPallini wrote:
still, I believe that
'i'is a better name than'index'It depends... In a very short for loop I usually prefer using 'i'. However, if I fill in some listbox/listcontrol I prefer using 'index' or 'item' rather than 'i'.
-
CPallini wrote:
The problem arises when you need to fill a listbox in a very short for loop.
No, it doesn't! :) :laugh: :suss::cool:
-
Quote:
If you type more, the resulting text should make your code more readable, not less
Verbosity does not imply clarity. Often writing less makes your text more readable ("Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte" :-D ).
Quote:
As a mathematician I do understand the advantage of short notation conventions. However, I also understand the problem of others not understanding your notation if they are not familiar with the shorthand notation you are using. So, if within your project team everyone agrees to certain shorthand notations, and actually take the time to document this (in case new members join the team), then the more power to you. Otherwise, just don't do it!
I do agree with you on this (still, I believe that
'i'is a better name than'index').CPallini wrote:
Verbosity does not imply clarity
That's why I said 'should'
CPallini wrote:
(still, I believe that
'i'is a better name than'index')I agree that 'index' is no more useful a name than 'i'. If there is any implied meaning to an index other than being the i'th element in a container, I prefer a variable name that reflects this meaning. For example if I have a curve consisting of several joined edges, I prefer 'edge_index' over 'i' or 'index'. Not only does this add clarity, it also makes my code extendable: if I later find I want to process each edge as a list of points, I have no problem naming the nested loop variable as 'point_index', and i wouldn't need to rename the existing loop variable.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
