Object.factory() and exe file size bloat

[deadalnix via Digitalmars-d]

On Friday, 21 August 2015 at 20:26:29 UTC, Walter Bright wrote:
> On 8/21/2015 6:29 AM, Andrei Alexandrescu wrote:
>> Knee-jerk reaction: sensible and meaningful, but we need to 
>> make a good case for
>> breaking code. -- Andrei
>
> The case is:
>
>   https://issues.dlang.org/show_bug.cgi?id=14758
>
> i.e. D being unusable for embedded systems because of bloat.
>
> And it always has been a little strange to make every class 
> available via Object.factory. I have a hard time imagining an 
> application for it that needed more than a handful of classes 
> available that way.
>
> The principle often used by languages (C, C++, Rust) is you 
> only pay for what you use. With Object.factory, every program 
> pays for it with every class, despite very few actual uses of 
> it.

That sound reasonable and I advocated for changing Object.factory 
in the past for this very reason.

That being said, if we are going to break code, we'd better be 
sure we do it for something that is worth it.

That mean we need a way for user to repro the feature, and I 
rather avoid a dirty hack to do it, as proposed here. A generic 
solution, for instance, could be for a superclass to be able to 
mixin something in all its child.

Such a feature can be used to make sure that all child have a 
mechanism to register themselves int he factory. Something à la

class Base {
     super mixin {
         shared this() {
             library.register(typeid(typeof(this)));
         }
     }
}

class Child : Base {
     // The super mixin also gets expanded here.
     // But this does not have the same type.
     // Both end up being registered, whatever that means.
}

Such a solution can be leveraged by any library or user to do 
whatever they want. Sounds a better approach to me that 
introducing hacks.