ModuleInfo, Object.localClasses(), and Object.find() - any users?

Steven Schveighoffer schveiguy at gmail.com
Tue Dec 13 01:39:43 UTC 2022


On 12/12/22 5:01 PM, Adam D Ruppe wrote:
> On Monday, 12 December 2022 at 21:49:41 UTC, cc wrote:
>> 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.
> 
> 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.)

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


More information about the Digitalmars-d mailing list