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

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

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.

>> 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...

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

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.