On 11/11/13 10:59 PM, deadalnix wrote:
On Tuesday, 12 November 2013 at 05:46:19 UTC, Andrei Alexandrescu wrote:
On 11/11/13 2:36 PM, Timon Gehr wrote:
On 11/11/2013 11:02 PM, deadalnix wrote:
On Sunday, 10 November 2013 at 12:39:35 UTC, Timon Gehr wrote:
What about Object.factory?
I always though of it as a misfeature.
Me too.
... 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.
Well I'm not "burdening", just trying to figure how to do it better.
So I ran `grep -r * -e 'Object.factory'` on my d folder. I have various
D project there. The only uses of Object.factory are the test suite of
dmd, ldc and GDC.
That really proves nothing.
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.
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, ...).
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.
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.
Andrei
