discrimination of constructors with same number of parameters

[Guilherme Vieira]

On Thu, Dec 30, 2010 at 3:19 PM, Steven Schveighoffer
<schveiguy at yahoo.com>wrote:

> On Thu, 30 Dec 2010 12:08:56 -0500, spir <denis.spir at gmail.com> wrote:
>
>  On Thu, 30 Dec 2010 17:10:00 +0100
>> "Jérôme M. Berger" <jeberger at free.fr> wrote:
>>
>>  Steven Schveighoffer wrote:
>>> > What I would suggest is static factory methods.  The issue with any
>>> kind
>>> > of typedef (be it with the soon-to-be-deprecated typedef keyword or
>>> with
>>> > a proxy struct), is that what does this mean?
>>> >
>>> > auto obj = new Foo([1, 2, 3], "blah");
>>> >
>>> > Is "blah" a filename or a message?
>>> >
>>> --> Error, Foo (int[], string) does not exist.
>>>
>>
>> Yes, you are right. Typedef-like solutions need core support by the
>> language with a kind of hint to the compiler... playing the role of type in
>> Jérôme's sample below.
>>
>
> I expected a definition like this:
>
> typedef string filename;
>
> this(int[] x, string message);
> this(int[] x, filename file);
>
> Which would be more ambiguous in usage.  So your version (with two
> typedefs) is better.
>
>
>>  > Whereas, if you use factory methods:
>>> >
>>> > auto obj = Foo.createWithFilename([1,2,3], "blah"); // "blah" is a
>>> filename
>>> > auto obj = Foo.createWithMessage([1,2,3], "blah"); // "blah" is a
>>> message
>>>
>>
>> Factory methods are definitely convenient. The single objection is rather
>> conceptual: it defeats the purpose of a major language feature, namely
>> constructor; which happens to have a clear meaning from the modelling point
>> of view.
>>
>
> This doesn't mean much to me.  I don't see the benefit of using 'new' vs.
> using a static factory method.  What is the "clear meaning" that
> constructors have that factory methods do not?
>
>
>>  > The code becomes crystal clear.  Reduce verbosity as you see fit ;)
>>> >
>>> auto obj = new Foo ([1, 2, 3], Filename ("blah"));
>>> auto obj = new Foo ([1, 2, 3], Message ("blah"));
>>>
>>
>> Conceptually, I would prefere this -- at the use place. But if requires
>> obfuscating the code at the definition point (with eg wrapper structs), is
>> it worth it?
>>
>> If we could write eg:
>>        typedef string Message;
>>        auto obj = new Foo ([1, 2, 3], Message ("blah"));
>> then I would be happy, I guess ;-)
>>
>>
> Wait, this isn't any different than using a wrapper struct...
>
> struct Message
> {
>   string value;
> }
>
> struct Filename
> {
>   string value;
> }
>
> class Foo
> {
>   string message;
>   string filename;
>   int[] arr;
>   this(int[] arr, Message m) {this.arr = arr; this.message = m.value;}
>   this(int[] arr, Filename f) {this.arr = arr; this.filename = f.value;}
> }
>
> How is that "obfuscation"?
>
> I still prefer the factory method solution, as it doesn't add unecessary
> types.
>
> -Steve
>

There's an idiom I'm quite fond of. There are some classes you shouldn't be
instantiating yourself.

Take for example a SoundSource class, which represents a source of sound in
a 2D or 3D environment. It's obvious that it requires the SoundSystem to be
initialized when it's created, unless it used lazy initialization of the
sound system (which I dislike, since everytime you create an object it'll
have to check whether the system is initialized or not).

As such, it makes sense that the architecture guide client developers to
only instantiate after initializing the system. If you normally simply
*new*SoundSources yourself, it's not hard to forget the sound system
initialization. So I prefer to make the SoundSystem class a factory of
SoundSources (Ogre3D does such things a lot), and it's particularly damn
great to create template methods such as these:

class SoundSystem
{
    Unique!(TSoundSource) createSource(TSoundSource, CtorArgs...)(CtorArgs
ctorArgs)
    {
        // reserves first argument for mandatory parameters, but leaves the
rest client-defined
        return new TSoundSource(this, ctorArgs);
    }
}

// later ...
sndSystem.createSource!(MySoundSource)(my, custom, parameters);


In this case, constructing the SoundSource required a SoundSystem as a
parameter, so yeah, you would need the thing to be able to instantiate
alright. But it surely gives margin to misuses: if you, as the library
developer, noticed that *any* SoundSource implementation should get the
SoundSystem upon construction from the caller (and not try to tell which
system to use by e.g. picking it from a singleton of the likes), then this
idiom is useful.

I find this kind of usage extremely expressive (in fact, I'd like to take
the moment the ask what the gurus think about it; I really have never seen
people doing this). It shows precisely how the library is meant to be used.

The least wrong things you can do, the better, so getting rid of the
possibility of instantiating things at the wrong times is certainly good.
And static factories succeed in making such things harder.

Yes, you could wrap classes in structs that would construct them using one
factory or another, but making useful idioms more and more cumbersome to use
is almost never a good idea:

struct MyObjectWithFileName // this
{ // is
    this(string fname) { obj = MyObject.createWithFilename(fname); } // so
    MyObject obj; // much
} // typing!

// later ...
manager.create!(MyObjectWithFileName)("filename.txt"); // phew..! now repeat
for every other overload


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

-- 
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20101230/0f842ec6/attachment-0001.html>