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
