On 6/4/2013 12:58 AM, Andrei Alexandrescu wrote:

Unless fresh arguments, facts, or perspectives come about, I am
personally not convinced, based on this thread so far, that we should
operate a language change.


The best you could do without a language change is to establish some good conventions for class design:

A) prefer writing UFCS functions
B) make it the norm for classes to segment their functions a lot like the public/private setup of C++ classes: Have blocks for final, override, final override. Ideally there is a virtual keyword there like the others.


At least in C++ land I can tell if a code library is useful to me by searching for how it uses virtuals, among other things like searching for catches and throws since I am stuck on platforms without exception handling and am working in a codebase that is designed without it.


I also find the idea that the linker could help a bit iffy since once you start DLLEXPORT'ing your classes the dependency tree basically expands to your whole codebase and it quickly cascades into being unable to eliminate most functions and global variables from the final image. You end up with fat binaries and its hard to prune dead stuff, and it has to be done by hand by walking the map files for iffy-objects and tracking down their dependencies. This is especially true if nearly everything is virtual.


I suppose in theory there is an alternative change which wouldn't require a new keyword, and that would be to make it so that methods are only virtual if they are defined in an interface, and forbidding them coming into existence at class scope. But this would increase the code maintenance probably a bit too much.


Reply via email to