Currently, the ModuleInfo struct generated for each module also includes a pointer to the ClassInfo for every class in that module.

The only reference to this data is in the functions Object.localClasses() and Object.find(). The idea is to be able to instantiate a class via a text string rather than a link to the name.

This adds a lot of extra size.

1. Does anybody use Object.localClasses() or Object.find() ?

2. Does anybody need them?

3. Could it be changed to only include the classes marked `export` ?

4. Could we just remove it entirely?

On Friday, 9 December 2022 at 22:20:28 UTC, Walter Bright wrote:
> 4. Could we just remove it entirely?

This is what we should do!

On Fri, Dec 09, 2022 at 02:20:28PM -0800, Walter Bright via Digitalmars-d wrote:
> Currently, the ModuleInfo struct generated for each module also includes a pointer to the ClassInfo for every class in that module.

Wow.  I had no idea such a thing even exists!


> The only reference to this data is in the functions
> Object.localClasses() and Object.find(). The idea is to be able to
> instantiate a class via a text string rather than a link to the name.
> 
> This adds a lot of extra size.
> 
> 1. Does anybody use Object.localClasses() or Object.find() ?

I don't.  Didn't even know they existed.


> 2. Does anybody need them?

Not me.


> 3. Could it be changed to only include the classes marked `export` ?

Sounds like a reasonably safe approach.


> 4. Could we just remove it entirely?

No idea if some D project somewhere out there might use it, so the spectre of code breakage is there...

But maybe it's possible to make this pay-as-you-go?  I.e., if nobody actually calls Object.localClasses or Object.find, then it won't be included.  Only if somebody actually references it, it will be included. Sorta like a template.  But I've no idea how feasible it is to implement such a thing.


T

-- 
I am not young enough to know everything. -- Oscar Wilde

On 10/12/2022 11:35 AM, H. S. Teoh wrote:
> But maybe it's possible to make this pay-as-you-go?  I.e., if nobody
> actually calls Object.localClasses or Object.find, then it won't be
> included.  Only if somebody actually references it, it will be included.
> Sorta like a template.  But I've no idea how feasible it is to implement
> such a thing.

Its a little too indirect I think.

I just can't see anything pulling in the symbol that have to be generated for the localClasses array and the linker will just strip it out.

On Sat, Dec 10, 2022 at 01:19:11PM +1300, rikki cattermole via Digitalmars-d wrote:
> On 10/12/2022 11:35 AM, H. S. Teoh wrote:
> > But maybe it's possible to make this pay-as-you-go?  I.e., if nobody actually calls Object.localClasses or Object.find, then it won't be included.  Only if somebody actually references it, it will be included.  Sorta like a template.  But I've no idea how feasible it is to implement such a thing.
> 
> Its a little too indirect I think.
> 
> I just can't see anything pulling in the symbol that have to be generated for the localClasses array and the linker will just strip it out.

One idea is to turn the array into a template function that returns an array, the instantiation of which somehow triggers the generation of the extra info.

But the question is, is this feature even being used at all in the first place... if not, pulling stunts of this sort is just wasted effort.


T

-- 
Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright

On 12/9/22 5:20 PM, Walter Bright wrote:
> Currently, the ModuleInfo struct generated for each module also includes a pointer to the ClassInfo for every class in that module.
> 
> The only reference to this data is in the functions Object.localClasses() and Object.find(). The idea is to be able to instantiate a class via a text string rather than a link to the name.
> 
> This adds a lot of extra size.
> 
> 1. Does anybody use Object.localClasses() or Object.find() ?
> 
> 2. Does anybody need them?
> 
> 3. Could it be changed to only include the classes marked `export` ?
> 
> 4. Could we just remove it entirely?

Please remove. You have to deprecate the functionality first (biggest problem is Object.factory). But it is broken anyway.

I have pointed this out for years. ModuleInfo *does* include this information. But it's not guaranteed to generate ModuleInfo just if a class is present. See for instance: https://issues.dlang.org/show_bug.cgi?id=16423

-Steve

On 12/9/2022 7:03 PM, Steven Schveighoffer wrote:
> I have pointed this out for years. ModuleInfo *does* include this information. But it's not guaranteed to generate ModuleInfo just if a class is present. See for instance: https://issues.dlang.org/show_bug.cgi?id=16423

Thanks for the link.

On 12/9/2022 7:03 PM, Steven Schveighoffer wrote:
> Please remove. You have to deprecate the functionality first (biggest problem is Object.factory). But it is broken anyway.

https://github.com/dlang/dmd/pull/14681

One way to find out who's using it.

On Saturday, 10 December 2022 at 04:05:14 UTC, Walter Bright wrote:
> On 12/9/2022 7:03 PM, Steven Schveighoffer wrote:
>> Please remove. You have to deprecate the functionality first (biggest problem is Object.factory). But it is broken anyway.
>
> https://github.com/dlang/dmd/pull/14681
>
> One way to find out who's using it.

There are some matches for these names when searching on Github. Most are Phobos forks, but there are some actual projects which seem to use those functionalities.

On 12/10/2022 12:52 PM, JN wrote:
> There are some matches for these names when searching on Github. Most are Phobos forks, but there are some actual projects which seem to use those functionalities.

Thank you, good to know.