Counterproposal for extending static members and constructors

[Jonathan M Davis]

On Thursday, July 12, 2012 12:54:44 H. S. Teoh wrote:
> On Thu, Jul 12, 2012 at 03:27:06PM -0400, Jonathan M Davis wrote:
> > On Thursday, July 12, 2012 18:25:03 David Piepgrass wrote:
> > > I'm putting this in a separate thread from
> > > http://forum.dlang.org/thread/uufohvapbyceuaylostl@forum.dlang.org
> > > because my counterproposal brings up a new issue, which could be
> > > summarized as "Constructors Considered Harmful":
> > > 
> > > http://d.puremagic.com/issues/show_bug.cgi?id=8381
> > 
> > I think that adding constructors to a type from an external source is
> > downright evil. It breaks encapsulation. I should be able to constrain
> > exactly how you construct my type. If you want to create a free
> > function (e.g. a factory function) which uses my constructors, fine.
> > But I'm completely against adding constructors externally.
> 
> [...]
> 
> Yeah, I think free-function ctors are not a good idea.
> 
> But unifying ctor syntax with object factories is a good idea IMO. It
> helps encapsulation: the users of class C don't have to know what the
> _actual_ object instance is, they just get a C reference, which could be
> an instance of D (which inherits from C). For example, I can write:
> 
> string url = ...;
> auto connection = new DBConnection(url);
> 
> If url points to a SQLite database, the DBConnection ctor can return an
> instance of SQLiteDBConnection; if url points to an Oracle database, the
> ctor can return an instance of OracleDBConnection. But the ctor could
> just as easily return an instance of DBConnection itself, if the class
> is designed to work across different database backends in a generic way.
> The user doesn't have to know this implementation detail.
> 
> The only concern is how this would interact with derived class ctors,
> since calling superclass ctor may not return what the derived class ctor
> is expecting. Other than this concern, though, I really like this idea.

If you want a factory function, then declare a factory function. I don't see 
why would need any special syntax for that, especially when what a factory 
function returns depends completely on what you're using it for rather than 
being even vaguely standard.

- Jonathan M Davis