On Friday, 9 December 2022 at 22:20:28 UTC, Walter Bright wrote:

This would affect Object.factory, yes? I've used that previously in commercial software.
Can partially work around it with std.traits.moduleName and __traits(allMembers, somemodule), but what other options are there for finding classes outside of the current module other than those explicitly referenced in the calling module?

On 12/12/22 3:40 PM, cc wrote:

You need to register those classes with a system, to replace the functionality that ModuleInfo and Object.factory provide.

But it would be better to do that anyway, since the compiler isn't completely consistent with which classes it inserts into ModuleInfo.

-Steve

On Monday, 12 December 2022 at 20:58:40 UTC, Walter Bright wrote:

This was an older project ported from Objective-C that read external definition data, looking at it now it can (and probably should) be replaced. The allowed class list still needed to be verified so it's the same issue of explicitly registering classes, so disregard that example.

In newer stuff I have RPC and serialization/remote object duplication libraries where I explicitly register modules to scan for classes by UDA (or have them indirectly register their own modules when one class calls in to the library). It would be nice to be able to preemptively scan/register classes in arbitrary modules without needing to list them in a second area of code. One (minor) example I have is a toString(OutputRange)() promoter that calls the correct templated function when the variable type doesn't match the typeid. This doesn't use ModuleInfo, but it could. If derived classes exist across multiple files, it can miss registering some of them if they call out of order. Otherwise I need to explicitly register each class I want handled here, which is the same "make one change in multiple places" problem that avoiding is one of my favorite strengths of D.

tl;dr I can live without it, but now that I'm reminded it exists, it seems like a nice thing to have. 😕

On Monday, 12 December 2022 at 21:49:41 UTC, cc wrote:

What I like to do is have classes register themselves. You can do a mixin RegisterThis; thing that you import from the lib. The downside is if you forget to register a child, it won't remind you until you try to use it. But the upside is you can do all kinds of custom work in there, it avoids scanning modules, and can be done without a central list.

The RegisterThis thing adds a static constructor that appends the factory to the runtime list.

Would be nice if druntime offered some thing like this to replace the existing Object.factory - you can migrate by like mixin imported!"core.factory".Register; to make it possible. Then an extra would-be-even-nicer is if there was some way so all objects that inherit from a parent or implement a particular interface either 1) reminded you to register it or 2) just self-registered automatically. (You can kinda do this with the curiously-recurring template pattern but still subclasses can fall through the cracks.)

On 12/12/22 5:01 PM, Adam D Ruppe wrote:

The downside there is if you run into cycles. Clearly, this isn't going to contribute to a cycle, but there's no way to specify that it won't.

A way to address cycle problems would be nice here. On one hand, you have to depend on a module that initializes the registry, so you depend on the static ctor sorting to work, but on the other hand, there aren't going to be any cycles for this particular thing. I'm not sure of the right answer, and I've thought about it a lot.

-Steve