https://issues.dlang.org/show_bug.cgi?id=16423
--- Comment #7 from Martin Nowak <c...@dawg.eu> --- (In reply to Steven Schveighoffer from comment #5) > This is penny-wise and pound-foolish. First we need to solve megabyte sized > template symbol names. Then we need full shared library support. The few > kilobytes that moduleinfo adds is nothing. Trim out unused classinfo? Then > we need to remove Object.factory method. - Yes we need to solve the long symbol names, but they don't bloat the code segment or affect the performance - shared libraries were just one workaround I named (and they can be fully used on linux/FreeBSD atm.) - It's not the ModuleInfo or the ClassInfo, it's the fact, that this drags in the complete tree of symbols reachable by any referenced class, i.e. the whole module in most cases. The static constructors and class references are one of the main reasons for our huge binaries (code segment, not file size which is just a distribution problem). - Object.factory is slow by design, it's in the interest of everyone to avoid that facility if possible, and there aren't many use-cases that really require it If we have enough prove that it's a necessary pattern, I'd be in favor of adding a global, synchronized, namespaced dynamic class registration facility in phobos or druntime. That could be used for certain patterns such as registering deserializable subclasses, factory.register!("orange.deserializer", MyOpenSubclass). It could also make use of a hash table to speed up instantiating, and maybe even support non-standard constructors. The question is really, do we really need it, and who builds it. --