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

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

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.

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.

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

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

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));
}

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

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);

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