Object.factory() and exe file size bloat

[Benjamin Thaut via Digitalmars-d]

On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
> This function:
>
>   http://dlang.org/phobos/object.html#.Object.factory
>
> enables a program to instantiate any class defined in the 
> program. To make it work, though, every class in the program 
> has to have a TypeInfo generated for it. This leads to bloat:
>
>   https://issues.dlang.org/show_bug.cgi?id=14758
>
> and sometimes the bloat can be overwhelming.
>
> The solution seems straightforward - only have Object.factory 
> be able to instantiate classes marked as 'export'. This only 
> makes sense anyway.
>
> What do you think?

I don't think this is a good idea. That's just abusing a already 
existing keyword. Export basically means "Make this function or 
class visible across shared library boundaries". I don't see how 
this connects to the object factory. Maybe I want to instantiate 
a class via the factory that should not be visible across a 
shared library boundary (e.g. to keep the interface of a shared 
library minimal).
Please also consider that as export means dllexport and dllimport 
at the same time (on Windows) classes marked with export will 
inflict additional runtime overhead due to the double indirection 
needed for dlls and due to the fact that you sometimes don't know 
if the class resides in a different binary then the one your are 
currently in.
This runtime overhead even occurs for purely static builds, as 
the compiler can't know if the generated code uses some shared 
library or not. (unless we add a specific compiler switch for it, 
like -onlyStatic which many people will not be a fan of. And no 
the -shared flag doesn't help as executables are build without 
-shared and might still use shared libraries)

Given how limited object.factory is I would just vote that we 
kill it completely. Every time I wanted to use it, it was to 
limited and I ended up building my own reflection / factory 
mechanism.

Even though you rejected my proposal for making export a 
attribute instead of a visibility level, I think that once a 
broader set of contributors sees the issue behind export being a 
protection level the demand will be high to make export an 
attribute. Giving export a additional meaning now will only 
complicate this.


Tldr: As broken as export currently is we shouldn't be using it 
for anything else.

Kind Regards
Benjamin Thaut