www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Counterproposal for extending static members and constructors

reply "David Piepgrass" <qwertie256 gmail.com> writes:
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
Jul 12 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jul 12, 2012 at 06:25:03PM +0200, 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

So, if I understand your proposal correctly, you're essentially saying that the ctor of a given class C may return a derived class of C instead of just C itself? Isn't this just the "object factory" pattern in disguise? T -- It is impossible to make anything foolproof because fools are so ingenious. -- Sammy
Jul 12 2012
parent deadalnix <deadalnix gmail.com> writes:
On 12/07/2012 19:37, H. S. Teoh wrote:
 On Thu, Jul 12, 2012 at 06:25:03PM +0200, 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

So, if I understand your proposal correctly, you're essentially saying that the ctor of a given class C may return a derived class of C instead of just C itself? Isn't this just the "object factory" pattern in disguise?

It is, and in D we don't need object factory, we just need a free function.
Jul 12 2012
prev sibling next sibling parent "David Piepgrass" <qwertie256 gmail.com> writes:
On Thursday, 12 July 2012 at 17:35:51 UTC, H. S. Teoh wrote:
 On Thu, Jul 12, 2012 at 06:25:03PM +0200, 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

So, if I understand your proposal correctly, you're essentially saying that the ctor of a given class C may return a derived class of C instead of just C itself?

No, it can also return a different class with the same name.
 Isn't this just the "object factory" pattern in disguise?

Is is a unification of syntax, just as UFCS is a unification of syntax. It solves multiple problems, including information hiding, and extending classes written by other parties.
Jul 12 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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. - Jonathan M Davis
Jul 12 2012
parent reply travert phare.normalesup.org (Christophe Travert) writes:
"Jonathan M Davis" , dans le message (digitalmars.D:172156), a écrit :
 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.

The proposal is not that add constructors. It is to create a free function (.make!Type(args)), that can called like a constructor, by writing Type(args). That does not break encapsulation.
Jul 12 2012
parent reply deadalnix <deadalnix gmail.com> writes:
On 13/07/2012 01:42, Jonathan M Davis wrote:
 On Thursday, July 12, 2012 21:23:56 Christophe Travert wrote:
 "Jonathan M Davis" , dans le message (digitalmars.D:172156), a écrit :
 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.

The proposal is not that add constructors. It is to create a free function (.make!Type(args)), that can called like a constructor, by writing Type(args). That does not break encapsulation.

But it _does_ make it look like you're using a constructor when you're not, which I'm against regardless. In any case, std.container already declares a make which encapsulates constructing an object without caring whether it's a struct or class (since some containers are one and some another), which I intend to move to std.typecons and make work with all types. That seems a lot more useful to me than trying to make a function act like a constructor when it's not - though I guess that as long as you imported std.typecons, I would just be providing the free function that your little constructor faking scheme needs. - Jonathan M Davis

+1
Jul 12 2012
parent reply travert phare.normalesup.org (Christophe Travert) writes:
 In any case, std.container already declares a make which encapsulates
 constructing an object without caring whether it's a struct or class (since
 some containers are one and some another), which I intend to move to
 std.typecons and make work with all types. That seems a lot more useful to me
 than trying to make a function act like a constructor when it's not - though I
 guess that as long as you imported std.typecons, I would just be providing the
 free function that your little constructor faking scheme needs.


The same can be said for UFCS. Your just faking member functions with a free function. I don't understand why constructors are so different. A library might write generic code and use a constructor to perform something. I can't use that generic code if I don't own the struct or class and am able to write a constructor. You can argue that the library should have use make, instead of calling the constructor or using some cast. But they can't think of every usages, and may not know about make. Plus it may make the code uglier. It's like standard UFCS. library writer should never call a member function, and always call a free function that is templated, specialised to use the member function if available, to provide workarround, or that can be further specialised if someone wants to extend the class. yuuuuk...
Jul 13 2012
parent deadalnix <deadalnix gmail.com> writes:
On 13/07/2012 11:00, Jonathan M Davis wrote:
 Constructors, on the other hand, are the complete opposite of generic, and
 they generally _can't_ be generic.

Amen.
Jul 13 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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. T -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
Jul 12 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/12/2012 09:54 PM, 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. T

Note that this is 'supported' today because of a compiler bug. class C{ this(){ this = new D; } protected this(int){} } class D : C{ this(){super(0);} } void main(){ C c = new C; assert(typeid(c) is typeid(D)); }
Jul 12 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On 12/07/2012 21:54, 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. T

You need a free function as a factory here. That is it.
Jul 12 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/12/2012 06:25 PM, 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 work around this issue by creating all objects like New!Type(args);
Jul 12 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, July 12, 2012 21:23:56 Christophe Travert wrote:
 "Jonathan M Davis" , dans le message (digitalmars.D:172156), a écrit :
 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.

The proposal is not that add constructors. It is to create a free function (.make!Type(args)), that can called like a constructor, by writing Type(args). That does not break encapsulation.

But it _does_ make it look like you're using a constructor when you're not, which I'm against regardless. In any case, std.container already declares a make which encapsulates constructing an object without caring whether it's a struct or class (since some containers are one and some another), which I intend to move to std.typecons and make work with all types. That seems a lot more useful to me than trying to make a function act like a constructor when it's not - though I guess that as long as you imported std.typecons, I would just be providing the free function that your little constructor faking scheme needs. - Jonathan M Davis
Jul 12 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jul 12 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, July 13, 2012 08:10:46 Christophe Travert wrote:
 In any case, std.container already declares a make which encapsulates
 constructing an object without caring whether it's a struct or class
 (since
 some containers are one and some another), which I intend to move to
 std.typecons and make work with all types. That seems a lot more useful
 to me than trying to make a function act like a constructor when it's
 not - though I guess that as long as you imported std.typecons, I would
 just be providing the free function that your little constructor faking
 scheme needs.


The same can be said for UFCS. Your just faking member functions with a free function. I don't understand why constructors are so different. A library might write generic code and use a constructor to perform something. I can't use that generic code if I don't own the struct or class and am able to write a constructor. You can argue that the library should have use make, instead of calling the constructor or using some cast. But they can't think of every usages, and may not know about make. Plus it may make the code uglier. It's like standard UFCS. library writer should never call a member function, and always call a free function that is templated, specialised to use the member function if available, to provide workarround, or that can be further specialised if someone wants to extend the class. yuuuuk...

The primary advantage of UFCS is in aiding generic code. It's what allows us to use arrays as ranges without adding front, popFront, etc. to the language itself. Constructors, on the other hand, are the complete opposite of generic, and they generally _can't_ be generic. Not only does whether you use new or not with them differ depending no the type, but the arguments required differ considerably from type to type even if their APIs are identical. It's the API of already constructed objects which makes things generic, not construction. make allows you to not care whether you're constructing a struct or a class (it uses new for a class and doesn't for structs), so it helps abstract that away, but it doesn't abstract away the arguments. What they need to be depends entirely on what's being constructed. Generic construction rarely makes sense. And I'd argue that if we don't already have too much magic with UFCS as it stands, then we're darn close. You can't look at a member function call any more and even know if it's a member function! Now you want to make it so that you can't even know if a constructor is a proper constructor? Yuck. - Jonathan M Davis
Jul 13 2012