discrimination of constructors with same number of parameters

Steven Schveighoffer schveiguy at yahoo.com
Thu Dec 30 11:26:21 PST 2010


On Thu, 30 Dec 2010 14:08:49 -0500, spir <denis.spir at gmail.com> wrote:

> On Thu, 30 Dec 2010 16:33:39 -0200
> Guilherme Vieira <n2.nitrogen at gmail.com> wrote:
>
>> When I create factory methods like those proposed in this thread, I feel
>> like I'm hijacking a core aspect of the language. Goddamn it, it's the
>> constructor! IMHO, everybody expects to construct things.. using
>> constructors (unless there's a restriction like not being allowed to
>> construct stuff anytime, but only under certain conditions, which was  
>> the
>> case with SoundSources).
>>
>> Factory methods should, again just in my opinion, be used to exploit
>> polymorphism or enhance the system design, not to solve problems of the
>> language dealing with method overloading. It's just.. creepy. Is it  
>> just me?
>> I feel like I'm giving too much and barely getting one thirth in  
>> return...
>
> @Steven: This is great answer to the question you asked me (and I did  
> not answer) about the "clear meaning" of constructors in a PL. (Else,  
> let's just get rid of them alltogether, and of the notion too, and just  
> use object factories?)

A factory method *forwards to* a constructor.  You are not losing the  
construction aspect (or its special qualities), in fact, it can sit beside  
a constructor.

There are many cases where a constructor is not as clear as a factory  
method.  Take for std.array.Appender.  The constructor that takes an  
initial array as input:

int[1024] buf;

auto app = Appender!(int[])(buf);

vs.

auto app = appender(buf);

The factory method looks clearer to me.

I think it's really subjective depending on the situation.  All I'm saying  
is that there is nothing IMO that rules out factory methods as  
construction means on principal.

-Steve


More information about the Digitalmars-d-learn mailing list