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
