DIP 45 - approval discussion

[Andrei Alexandrescu]

On 11/12/13 6:03 PM, Timon Gehr wrote:
> 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

Fair point.

>>> - 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.

Wait, doesn't Object.factory call the default constructor of the created 
object?

>> 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.

If not the default constructor, which constructor? Didn't you say above 
that calling the default constructor is good? I feel we're talking past 
each other.

>> 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.

That would be indeed nice. But I have the feeling a significant part of 
this dialog is marred by confusion.


Andrei