On 2015-08-21 12:44, Walter Bright wrote:

> Object.factory() only has a point when it is used to instantiate classes
> in a DLL/so. It fits in nicely with export.

It's useful for deserialization as well.

-- 
/Jacob Carlborg

On Friday, 21 August 2015 at 13:11:14 UTC, Iain Buclaw wrote:
>> If it is guaranteed, almost makes me want to abuse it for this:
>>
>> pragma(inline, true)
>> string foo()
>> {
>>     if (!__ctfe)
>>         assert(false);
>>     // ...
>> }
>>
>> (for compilers other than LDC)
>>
>
> That enforces that foo() is always folded at compile time, not always
> inlined, no?

And when you combine both you gets function that is always folded at compile time and does not bloat the generated object file (like it happens right now with CTFE-only functions - they are still emitted to the binary). Win.

Of course, with LDC it is not an issue because they got --gc-sections working and CTFE utils get garbage collected :P

On Friday, 21 August 2015 at 13:18:17 UTC, Jacob Carlborg wrote:
> On 2015-08-21 12:44, Walter Bright wrote:
>
>> Object.factory() only has a point when it is used to instantiate classes
>> in a DLL/so. It fits in nicely with export.
>
> It's useful for deserialization as well.

Btw we use it for high-level testing framework - will be rather hard to move that to compile-time approach until some reflection bugs gets fixed.

On 8/21/15 1:06 AM, 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?

Knee-jerk reaction: sensible and meaningful, but we need to make a good case for breaking code. -- Andrei

On 8/21/15 7:03 AM, Mike wrote:
> On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
>> On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
>>> Disabling TypeInfo forces one to compromise on slicing, postblit
>>
>> Why slicing and postblit would need typeinfo?
>
> See below for the source code.  Some obvious, some not.
>
> * dynamic cast -
> https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-83bcb64558f947e39f87d7435709dfe7R364
>
> * array literal -
> https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-bed7d2226948b1e098749985d7a60633R2353
>
> * postblit -
> https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR918
>
> * destructor -
> https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR1039,
> https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-867588d7078efd0364c256152fb5a2e7R2053
>
> * new -
> https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R5091
>
> * AAs -
> https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R10710
>
> * slicing -
> https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R11857
>
>
> etc...
>
> Disabling TypeInfo requires quite a compromise on D's features. I want
> TypeInfo, I just don't want dead code.
>
> Mike

Thanks for this list. I think these need to be fixed (by replacing indirect-calls-based code with templates) regardless of where we go with TypeInfo. There's a fair amount of druntime code that suffers from being written before templates or in avoidance thereof. -- Andrei

How expensive putting a flag for the compiler?

--exportall, -ea

to export all, otherwise, only the classes with "export" keyword are to be exported.

On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
> On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
>> Disabling TypeInfo forces one to compromise on slicing, postblit
>
> Why slicing and postblit would need typeinfo?

Because the runtime implementation is broken and rely on it instead of templates.

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.

On 8/21/2015 6:29 AM, Dicebot wrote:
> On Friday, 21 August 2015 at 13:18:17 UTC, Jacob Carlborg wrote:
>> On 2015-08-21 12:44, Walter Bright wrote:
>>
>>> Object.factory() only has a point when it is used to instantiate classes
>>> in a DLL/so. It fits in nicely with export.
>>
>> It's useful for deserialization as well.
>
> Btw we use it for high-level testing framework - will be rather hard to move
> that to compile-time approach

It's good to hear of use cases for Object.factory.

> until some reflection bugs gets fixed.

Bugzilla issues? (You knew that was coming!)

On 8/21/2015 4:44 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net> wrote:
> Just change Object.factory to require registration of the class.

What mechanism do you propose for that?