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.
