DIP 45 - approval discussion

[deadalnix]

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.

>> I have bunch of D code in there, not simply mine. So first 
>> thing : it is
>> unused.
>> Secondly, the only useful things you can do with that require 
>> to upcast
>> (and break basic OOP principle, which is kind of ironic for a 
>> feature
>> that produce objects). The design of the feature is unsound.
>
> 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.

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.

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.

>> 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.

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

>> 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.

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

>> 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.