On 8/20/2015 11:40 PM, Jacob Carlborg wrote:
> I think, or rather know, that this will break serialization, i.e. my library
> Orange [1]. I really like that one doesn't need to register a class to be able
> to (de)serialize it.
>
> I can't believe this change is purposed that will clearly break valid code.

A large purpose of starting this thread is to find out in advance what sort of breakage would be likely, and explore ways to mitigate that breakage.


> But at the same time there are other breaking changes you refuse to do that would
> fix design flaws in the language.

As with everything, it's cost/benefit. Changing isnan to isNaN is an example of all cost and no benefit.

I've explained the benefits of changing factory() a couple times in this thread. I believe the benefits are significant, including the benefit of making D viable for use in embedded systems.


> I still remember your rant about your old D1 project that didn't compile with
> the latest D2 compiler.

Many of the breaking changes were gratuitous (all cost and no benefit), and some required rewrites so extensive I (along with invaluable help from Dmitry) created undeaD to deal with it:

https://github.com/DigitalMars/undeaD

On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:

> What do you think?

Do function pointer types also have TypeInfo? Derelict libraries has hundreds of them and my belief is that they are related. There were complaints about bloat at times. Those function pointer types typically don't need anything that TypeInfo provides.

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.

On Friday, 21 August 2015 at 21:37:34 UTC, Walter Bright wrote:
> 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?

http://forum.dlang.org/post/fxansmxbiobeshefszlm@forum.dlang.org

On 8/21/2015 6:27 AM, Dicebot wrote:
> 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.

They are emitted as COMDATs, and as such are not emitted to the binary (at least on Windows, where COMDATs actually work).

On 8/21/2015 2:59 PM, deadalnix wrote:
>[...]

It's a good idea, but is still equivalent to manually annotating the classes one wishes to register, and still requires a new language feature.

On 8/21/2015 2:53 PM, ponce wrote:
> Do function pointer types also have TypeInfo? Derelict libraries has hundreds of
> them and my belief is that they are related.

Compile with -map and check to see what winds up in the binary.

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?

Can't this be optional?
-slim-rtti        // hold the gravy
-verbose-rtti  // more gravy!


> On Friday, 21 August 2015 at 20:26:29 UTC, Walter Bright wrote:
>[...]
> 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.

Object.factory() would probably get more use if D provided a full solution in this category.

OffsetTypeInfo was never implemented, but is still collecting dust:
https://github.com/D-Programming-Language/druntime/blob/master/src/object.d#L197

I would love to see OffsetTypeInfo implemented, and have the field name included as well so it could be used for serialization.

I don't believe there has to be a "one size fits all" solution for this. Some people need small binaries, some need utility.

    Bit

On Friday, 21 August 2015 at 22:21:43 UTC, Walter Bright wrote:
> On 8/21/2015 2:59 PM, deadalnix wrote:
>>[...]
>
> It's a good idea, but is still equivalent to manually annotating the classes one wishes to register, and still requires a new language feature.

Breaking the code must be worth it.

On Friday, 21 August 2015 at 21:59:30 UTC, deadalnix wrote:
>
> 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.

+1, this seems like a great solution.

now if only typeinfo could be completely redone...