On Friday, 21 August 2015 at 05:24:52 UTC, BBasile wrote:
> 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:
...
>
> Other alternatives would be a pragma or an attribute to disable TypeInfo generation.
> @NoTI.


1. "Since it is compiled in the {$M+} state, the compiler generates RTTI (Run-Time Type Information) for it and all classes that descend from it."

http://freepascal.org/docs-html/rtl/classes/tpersistent.html



2. "Published properties are included in RTTI, public properties aren't"

http://stackoverflow.com/questions/3157648/whats-the-difference-between-public-and-published-class-members-in-delphi

On 2015-08-21 07:06, 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?

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. But at the same time there are other breaking changes you refuse to do that would fix design flaws in the language.

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

[1] https://github.com/jacob-carlborg/orange

-- 
/Jacob Carlborg

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?

I don't think this is a good idea. That's just abusing a already existing keyword. Export basically means "Make this function or class visible across shared library boundaries". I don't see how this connects to the object factory. Maybe I want to instantiate a class via the factory that should not be visible across a shared library boundary (e.g. to keep the interface of a shared library minimal).
Please also consider that as export means dllexport and dllimport at the same time (on Windows) classes marked with export will inflict additional runtime overhead due to the double indirection needed for dlls and due to the fact that you sometimes don't know if the class resides in a different binary then the one your are currently in.
This runtime overhead even occurs for purely static builds, as the compiler can't know if the generated code uses some shared library or not. (unless we add a specific compiler switch for it, like -onlyStatic which many people will not be a fan of. And no the -shared flag doesn't help as executables are build without -shared and might still use shared libraries)

Given how limited object.factory is I would just vote that we kill it completely. Every time I wanted to use it, it was to limited and I ended up building my own reflection / factory mechanism.

Even though you rejected my proposal for making export a attribute instead of a visibility level, I think that once a broader set of contributors sees the issue behind export being a protection level the demand will be high to make export an attribute. Giving export a additional meaning now will only complicate this.


Tldr: As broken as export currently is we shouldn't be using it for anything else.

Kind Regards
Benjamin Thaut

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:
> What do you think?

Can't we just make that Object.factory() an empty template and lazily instantiate class TypeInfo when needed.

On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
> What do you think?

Isn't typeinfo referenced from vtbl? So as long as the class is used, its typeinfo stays.

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?

On 2015-08-21 09:24, Benjamin Thaut wrote:

> Given how limited object.factory is I would just vote that we kill it
> completely. Every time I wanted to use it, it was to limited and I ended
> up building my own reflection / factory mechanism.

How is it limiting? That it only works with default constructors? I don't think that underlying ClassInfo.find is limiting, which is where the interesting part happens. I'm pretty sure that Object.factory could be extended to support non-default constructors, if that makes it less limiting.

-- 
/Jacob Carlborg

On Friday, 21 August 2015 at 08:49:37 UTC, Jacob Carlborg wrote:
>
> How is it limiting? That it only works with default constructors? I don't think that underlying ClassInfo.find is limiting, which is where the interesting part happens. I'm pretty sure that Object.factory could be extended to support non-default constructors, if that makes it less limiting.

Yes, the usual problem was that it only works with default constructors. Also it doesn't work with nested classes e.g.

class Outer
{
  class Inner
  {
  }
}

I don't know if that is fixed now.

Am Fri, 21 Aug 2015 07:24:58 +0000
schrieb "Benjamin Thaut" <code@benjamin-thaut.de>:

> I don't think this is a good idea. That's just abusing a already existing keyword. Export basically means "Make this function or class visible across shared library boundaries".

+1. I think we should be very careful when reusing a keyword which isn't fully specified.

Am Thu, 20 Aug 2015 22:21:30 -0700
schrieb "H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com>:

> On Fri, Aug 21, 2015 at 05:15:00AM +0000, deadalnix via Digitalmars-d wrote:
> > 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?
> > 
> > Wait ? Why only classes marked export ? I don't follow the reasoning here.
> 
> Because if your code imports the module that defines the class, you already know the class name (either by design, or by compile-time introspection) so you don't need to use the object factory.  It's only when you want to dynamically load new classes at runtime that you didn't know about at compile-time, that you need to use the object factory -- and that's also when you'd mark classes as 'export'.
> 
> Makes sense to me.
> 
> 
> T
> 

As Benjamin explained export works on library level, not on module level. You export from a library (DLL/.so) not from a module, so the analogy with D's 'import' is flawed.