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