DIP 45 - approval discussion

[Andrei Alexandrescu]

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