January 17, 2023
On Friday, 9 December 2022 at 22:20:28 UTC, Walter Bright wrote:
> Currently, the ModuleInfo struct generated for each module also includes a pointer to the ClassInfo for every class in that module.

I was planning to use "localClasses" to build a factory aware of classes to instantiate. The approach with mixin template doesn't look that handy, it is easy to forget it.

It would be great to have another way of registering classes in factory, but as I can see there is only localClasses is straight forward option as for me.

So let me please know, if it is going to deprecated soon.

Thank you


February 12, 2023
On Tuesday, 17 January 2023 at 08:43:50 UTC, psyscout wrote:
> On Friday, 9 December 2022 at 22:20:28 UTC, Walter Bright wrote:
>> Currently, the ModuleInfo struct generated for each module also includes a pointer to the ClassInfo for every class in that module.
>
> I was planning to use "localClasses" to build a factory aware of classes to instantiate. The approach with mixin template doesn't look that handy, it is easy to forget it.
>

I have trodden the path of mixin templates. I believe the only way to register classes for a factory mechanism is to involve "static this" constructors.

For any non-trivial code it gets me to unresolvable circular dependencies in the modules. I request the developers not to rush with deprecating Object.factory until a mechanism is developed to creak circular dependencies with modules. I see some discussion on the following thread which may be related to what I am trying to say.

https://forum.dlang.org/post/mailman.1221.1513724189.9493.digitalmars-d@puremagic.com
February 12, 2023
I meant "until a mechanism is developed to break circular dependencies between the modules"
.
February 12, 2023
On Friday, 9 December 2022 at 22:20:28 UTC, Walter Bright wrote:
> 4. Could we just remove it entirely?

Yes.
February 13, 2023
On 13/02/2023 3:46 AM, Puneet Goel wrote:
> I meant "until a mechanism is developed to break circular dependencies between the modules".

There is a mechanism to do this. Rearchitect your code, you need more leafs in your codebase.

The druntime check is a sort, it exists for a reason, it also fails because of your code. There is nothing to do on the druntime/dmd side.
February 12, 2023
On 2/12/2023 6:44 AM, Puneet Goel wrote:
> I have trodden the path of mixin templates. I believe the only way to register classes for a factory mechanism is to involve "static this" constructors.
> 
> For any non-trivial code it gets me to unresolvable circular dependencies in the modules. I request the developers not to rush with deprecating Object.factory until a mechanism is developed to creak circular dependencies with modules. I see some discussion on the following thread which may be related to what I am trying to say.
> 
> https://forum.dlang.org/post/mailman.1221.1513724189.9493.digitalmars-d@puremagic.com

Your wish is my command:

https://github.com/dlang/dmd/pull/14699
February 13, 2023
On Monday, 13 February 2023 at 00:36:30 UTC, Walter Bright wrote:
> Your wish is my command:
>
> https://github.com/dlang/dmd/pull/14699


How is that supposed to work?
February 12, 2023
On 2/12/2023 5:29 PM, Adam D Ruppe wrote:
> On Monday, 13 February 2023 at 00:36:30 UTC, Walter Bright wrote:
>> Your wish is my command:
>>
>> https://github.com/dlang/dmd/pull/14699
> 
> 
> How is that supposed to work?

https://github.com/dlang/dlang.org/pull/3524
February 12, 2023
On 12/12/2022 9:29 PM, Steven Schveighoffer wrote:
> If Object.factory is to be a supported feature (I don't think it should be), then it has to include *all* classes. Otherwise, you have odd unrelated conditions that break the feature, and something that brittle really shouldn't be used.

It doesn't need to support all classes. The user is going to know which modules he wants to find the classes in.

February 13, 2023
On Monday, 13 February 2023 at 04:04:48 UTC, Walter Bright wrote:
>> How is that supposed to work?
>
> https://github.com/dlang/dlang.org/pull/3524

So it doesn't work and you don't even understand why.