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
next sibling 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 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 "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
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 reply 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
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 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