On 2013-11-12 08:52, Jacob Carlborg wrote:

> I used it in my serialization library, Orange, and it will be used in
> std.serialization when I finish that project.

Well, technically I'm using ClassInfo.find.

-- 
/Jacob Carlborg

On 11/11/13 11:58 PM, deadalnix wrote:
> On Tuesday, 12 November 2013 at 07:16:03 UTC, Andrei Alexandrescu wrote:
>> That really proves nothing.
>>
>
> That doesn't prove anything. But that doesn't smell good for the
> usefulness of the feature either.

My code doesn't use that, either. But it also doesn't use things like .toString for classes. It's just that I don't do much OOP in D - doesn't mean OOP and/or factory etc are bankrupt.

>> I think you're wrong here (even after one discounts for
>> s/upcast/downcast/). There's no breakage of any basic OOP principle.
>> There's no irony. Polymorphic creation aka the factory pattern is a
>> classic in object-oriented design. You'd have a bad time arguing
>> against it with anyone.
>>
>
> A Factory is always a factory of something. A factory fit nicely into
> the OOP paradigm as it allow the user of the object to not know what is
> the actual type of the object, but its interface.

Yes. Generalized, it stands to reason that Object (as the most inclusive class type) could plausibly have a factory.

> A factory is also in charge of all the work necessary to put the object
> in a useful state. Object.factory do not allow any of this.

But default class constructors can be elaborate, so one can assume the default constructor puts the object in a useful state. Granted, we could have added constructors with e.g. Variant parameters. But that would be just an enhancement.

> It doesn't make any sense to provide a factory of everything. The
> factory user will have to know what is built, at least partially to use
> it. This defeat the whole principle of a factory.

I don't see any defeating here. I do see a desire to specialize factories for specific subhierarchies, which is entirely fine. I don't see how that doesn't make a factory dealing in Object bad.

>>> It is not that surprising as different possible uses case are better
>>> solved with compile time reflection and metaprograming.
>>
>> These don't take care of the dynamic case, which is sometimes needed
>> (wherever factories are useful: serialization, scripting, ...).
>>
>
> It is actually quite easy to create runtime capabilities from these
> basic blocs. CTFE allow to create AA, and at this point, the user can
> get whatever is desired at runtime.

What's missing is a list of all class types in the system. This is a fundamental issue with factories.

> This feature has more to do with runtime reflection than OOP.

Implementation-wise, yes. Conceptually, people often see them as virtual constructors (i.e. an OOP notion extended to construction).

>>> Implementationwise, this feature require to pull into the application
>>> some unoptimizable bloat.
>>
>> This is a good point. But I presume the dedicated code is small in size.
>>
>
> The code in itself isn't really the problem. The compiler have to emit a
> bunch of wiring to make it work. Wiring which is almost never used.
> Basically, the compiler have to emit runtime reflection informations,
> but just for classes.

One question would be whether the same work is needed for e.g. typeid() or toString. If not, maybe there is a case against factory.

> This seems to be the wrong tradeoff : we get the constraint of runtime
> reflection in term of design, but with very limited benefices.

I don't see how the existing system prevents you from rolling your own.

>>> It is also a tedious constraint for shared objects as we see in this
>>> thread.
>>
>> My reading of the thread is that there are concerns about DIP 45
>> beyond support of factories for shared objects.
>>
>
> This is A concern. Surely not the only one. That is why I didn't
> expanded myself on the subject in the first place. Simply that if we had
> to choose between this DIP and Object.factory, it is a braindead choice.

The time difference is crucial here. If this DIP came up in 2006 (when I estimate we introduced Object.factory) probably a lot of things would have come down differently. Proposals made in different epochs are, I think, very difficult to compare.


Andrei

Am 12.11.2013 09:50, schrieb Andrei Alexandrescu:
>
> The time difference is crucial here. If this DIP came up in 2006 (when I
> estimate we introduced Object.factory) probably a lot of things would
> have come down differently. Proposals made in different epochs are, I
> think, very difficult to compare.
>
>
> Andrei
>

Wait. Whats the actual issue here? This DIP does not prevent object.factory from working across DLL boundaries. This DIP does also not conflict with object.factory. So what is the actual problem at hand?

On Tuesday, 12 November 2013 at 08:50:29 UTC, Andrei Alexandrescu wrote:
> One question would be whether the same work is needed for e.g. typeid() or toString. If not, maybe there is a case against factory.
>

That isn't the same. toString itself rely on typeid. And the typeid object is stored with the virtual function table. The code can retrieve that information for any object, even the ones that the code never heard about.

Object.factory require the inverse: finding the typeid from the name of the class. It require to build some structure that associate the name of a class and its typeid, and make it available for Object.factory.

> I don't see how the existing system prevents you from rolling your own.
>

It doesn't, but I still need to pay for it.

> The time difference is crucial here. If this DIP came up in 2006 (when I estimate we introduced Object.factory) probably a lot of things would have come down differently. Proposals made in different epochs are, I think, very difficult to compare.
>

I understand some design has been made for historical reasons. That happen to every system. That doesn't mean much.

On 11/12/13 1:30 AM, Benjamin Thaut wrote:
> Am 12.11.2013 09:50, schrieb Andrei Alexandrescu:
>>
>> The time difference is crucial here. If this DIP came up in 2006 (when I
>> estimate we introduced Object.factory) probably a lot of things would
>> have come down differently. Proposals made in different epochs are, I
>> think, very difficult to compare.
>>
>>
>> Andrei
>>
>
> Wait. Whats the actual issue here? This DIP does not prevent
> object.factory from working across DLL boundaries. This DIP does also
> not conflict with object.factory. So what is the actual problem at hand?

You're right. I was meaning that in the abstract - generally feature creation is strongly conditioned by existing context.

Andrei

Am 12.11.2013 07:59, schrieb deadalnix:
> On Tuesday, 12 November 2013 at 05:46:19 UTC, Andrei Alexandrescu wrote:
>>
>> ... well time to substantiate.
>>
>> Andrei
>
> OK, but first, it has to be noted that this is putting the burden of
> proof on the wrong side of the argument.
>

But what is the actual argument? What problem do you see regarding object.factory and this DIP?

On Sunday, 10 November 2013 at 19:34:32 UTC, Walter Bright wrote:
> On 11/10/2013 4:13 AM, Benjamin Thaut wrote:
> Actually, it isn't entirely clear to me why the moduleinfo needs to be exported.
>
That depends on whether using a module might require to link against the moduleinfo, currently it does. For example there is an importedModules property in ModuleInfo.

> The moduleinfo is needed to run the static ctors/dtors, etc., but that is needed by the code internal to the dll that initializes the dll.

Initialization order is not an issue here, the whole DLL (and all modules) is initialized before any DLL/exe that depends on it.

On Sunday, 10 November 2013 at 12:03:53 UTC, Timon Gehr wrote:
> Using the export attribute on some member exports the entire module info. If I understand this right, the module info will contain information also about non-exported members of the module and therefore even non-exported members will be accessible from outside. Is this correct?

Yes, the module infos provide basic runtime reflection which can be used to access non-exported members.

On Sunday, 10 November 2013 at 19:47:16 UTC, Walter Bright wrote:
> It's long been recognized that using global variables to communicate between interfaces is a bad idea. And it isn't even supported for dlls, because the proposed solution to making them work is to wrap them with a function (much like D properties).
>
> We'd be going out of our way to support a recognized bad paradigm. There is currently no existing D code that requires this. If we add it, then we'd be stuck with supporting it for backwards compatibility. If we don't add it, and it becomes some sort of crisis that it isn't supported, we can add it in later without breaking things.

Yes, data interfaces (be it TLS or __gshared) are bad and make it more difficult to maintain a stable ABI. I also agree that TLS accesses shouldn't be a big problem.

On Sunday, 10 November 2013 at 21:50:51 UTC, Benjamin Thaut wrote:
> You completely ignored my inlining argument. Lets assume there is some small function that qualifies for inlining but accesses a TLS variable marked with the export attribute.

That's not an issue, you can't inline exported functions.
This is because the actual implementation is only know at link-time (only at run-time on UNIX).