Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Your argument seems to be "Java can be bad at this because it assumes an IDE, but C++ can't because it can't assume an IDE". Which is nonsense. If anything nested namespaces make sense in C++ but don't in Java, since Java has no nesting semantics and doesn't have using aliases. In Java it's just raw noise, whereas in C++ it's actual structure. Java isn't getting "benefits" from deep package paths.

Absl's arguments are that you shouldn't use that structure much, so you should avoid deep nesting (specifically deep nesting, not no nesting). But it actually does something in C++, which isn't true in Java. And that's really the core of Absl's complaints about nesting - don't copy your Java package name (which is irrelevant useless noise) to your C++ code (where it's actual structure, and collisions can result in issues)



I thought Titus's tip spells it out pretty well. In Java we know Doodad is some.long.package.hierarchy.Doodad and not some.Doodad or some.other.Doodad or an.entirely.different.Doodad because we explicitly wrote that down. The tooling helps you with spelling but the language provides exactly what is needed here.

If you introduce ambiguity, the code won't compile.

In C++ too bad, you wrote Doodad and thought you were getting ::some::new::package::hierarchy::Doodad however that doesn't actually exist, you were thinking of ::some::long::package::hierarchy::Doodad and your compiler didn't complain because it silently concludes you wanted ::some::Doodad which does exist (maybe it was added years ago and is rarely used, or maybe it was added in the new version you got last week) even though you never actually wanted anything from ::some itself. C++ loves ambiguity, because now it's your fault this happened, you were less than perfect and as such unworthy of the power and grace of C++




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: