DIP 45 - approval discussion
Timon Gehr
timon.gehr at gmx.ch
Tue Nov 12 18:03:15 PST 2013
On 11/12/2013 11:45 PM, Andrei Alexandrescu wrote:
>> - Every class in any imported module will need to show up in the
>> generated code even if it is never used unless global static analysis is
>> carried out on arguments to Object.factory.
>
> Correct. On the other hand, a lot of unused classes
It is not necessary that there are a lot. Anything transitively
reachable from there will be pulled in.
> in used modules
> seems to indicate a problem with the system's design.
>
Those could be classes that are only used at compile time, like a
builder for a grammar for a CTFE parser generator, for lack of a better
example. Furthermore, library modules may be larger than their actively
used interface. (Phobos?) It would be interesting to see how much
Object.factory influences the size of hello world, even though Phobos
does not use too many classes
>> - If I know the fully qualified name of a class, there are better ways
>> to instantiate this class than passing a string containing that name to
>> Object.factory in order to call the default constructor.
>
> What are the better ways?
Call the default constructor. Call a delegate/virtual function that
calls the default constructor.
> Note that most of the time you don't "know"
> the name of a class - you get it down the wire during some
> deserialization.
You don't want to call the default constructor during deserialization
and you need actual information about the Object layout, so seems to be
an instance of the next point.
> So there must be some way to build an object from a
> token representation of the object.
>
>> - The functionality provided by Object.factory is trivially replaced by
>> a solution more specifically tailored to the problem at hand using
>> compile-time reflection.
>
> It's not quite trivial - somewhere there has to be a map and
> registration and lookup and whatnot. I don't see it why it's unbecoming
> for such functionality to be part of the standard library. I would
> agree, however, that it's a judgment call whether it should be wired in
> or provided on demand.
I think that if supported at all, it should be an UDA declared somewhere
in druntime.
More information about the Digitalmars-d
mailing list