<div class="gmail_quote">On Thu, Dec 30, 2010 at 3:19 PM, Steven Schveighoffer <span dir="ltr"><<a href="mailto:schveiguy@yahoo.com">schveiguy@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, 30 Dec 2010 12:08:56 -0500, spir <<a href="mailto:denis.spir@gmail.com" target="_blank">denis.spir@gmail.com</a>> wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Thu, 30 Dec 2010 17:10:00 +0100<br>
"Jérôme M. Berger" <<a href="mailto:jeberger@free.fr" target="_blank">jeberger@free.fr</a>> wrote:<br>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Steven Schveighoffer wrote:<br>
> What I would suggest is static factory methods. The issue with any kind<br>
> of typedef (be it with the soon-to-be-deprecated typedef keyword or with<br>
> a proxy struct), is that what does this mean?<br>
><br>
> auto obj = new Foo([1, 2, 3], "blah");<br>
><br>
> Is "blah" a filename or a message?<br>
><br>
--> Error, Foo (int[], string) does not exist.<br>
</blockquote>
<br></div><div class="im">
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.<br>
</div></blockquote>
<br>
I expected a definition like this:<br>
<br>
typedef string filename;<br>
<br>
this(int[] x, string message);<br>
this(int[] x, filename file);<br>
<br>
Which would be more ambiguous in usage. So your version (with two typedefs) is better.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Whereas, if you use factory methods:<br>
><br>
> auto obj = Foo.createWithFilename([1,2,3], "blah"); // "blah" is a filename<br>
> auto obj = Foo.createWithMessage([1,2,3], "blah"); // "blah" is a message<br>
</blockquote>
<br></div><div class="im">
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.<br>
</div></blockquote>
<br>
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?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The code becomes crystal clear. Reduce verbosity as you see fit ;)<br>
><br>
auto obj = new Foo ([1, 2, 3], Filename ("blah"));<br>
auto obj = new Foo ([1, 2, 3], Message ("blah"));<br>
</blockquote>
<br></div><div class="im">
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?<br>
<br>
If we could write eg:<br>
typedef string Message;<br></div><div class="im">
auto obj = new Foo ([1, 2, 3], Message ("blah"));<br></div><div class="im">
then I would be happy, I guess ;-)<br>
<br>
</div></blockquote>
<br>
Wait, this isn't any different than using a wrapper struct...<br>
<br>
struct Message<br>
{<br>
string value;<br>
}<br>
<br>
struct Filename<br>
{<br>
string value;<br>
}<br>
<br>
class Foo<br>
{<br>
string message;<br>
string filename;<br>
int[] arr;<br>
this(int[] arr, Message m) {this.arr = arr; this.message = m.value;}<br>
this(int[] arr, Filename f) {this.arr = arr; this.filename = f.value;}<br>
}<br>
<br>
How is that "obfuscation"?<br>
<br>
I still prefer the factory method solution, as it doesn't add unecessary types.<br>
<br>
-Steve<br>
</blockquote></div><br>There's an idiom I'm quite fond of. There are some classes you shouldn't be instantiating yourself.<div><br></div><div>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).<div>
<br></div><div>As such, it makes sense that the architecture guide client developers to only instantiate after initializing the system. If you normally simply <b>new</b> 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:</div>
</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><font class="Apple-style-span" face="'courier new', monospace">class SoundSystem</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">{</font></div></div><div><font class="Apple-style-span" face="'courier new', monospace"> Unique!(TSoundSource) createSource(TSoundSource, CtorArgs...)(CtorArgs ctorArgs)</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"> {</font></div><div><font class="Apple-style-span" face="'courier new', monospace"> // reserves first argument for mandatory parameters, but leaves the rest client-defined</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"> return new TSoundSource(this, ctorArgs);</font></div><div><font class="Apple-style-span" face="'courier new', monospace"> }</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">}</font></div><div><font class="Apple-style-span" face="'courier new', monospace"><br></font></div><div><font class="Apple-style-span" face="'courier new', monospace">// later ...</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">sndSystem.createSource!(MySoundSource)(my, custom, parameters);</font></div></blockquote><div style="font-family: 'courier new', monospace; ">
<br></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">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.</font></div>
<div><font class="Apple-style-span" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">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.</font></div>
<div><font class="Apple-style-span" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">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.</font></div>
<div><font class="Apple-style-span" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">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:</font></div>
<div><font class="Apple-style-span" face="arial, helvetica, sans-serif"><br></font></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><font class="Apple-style-span" face="'courier new', monospace">struct MyObjectWithFileName // this</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">{ // is</font></div><div><font class="Apple-style-span" face="'courier new', monospace"> this(string fname) { obj = MyObject.createWithFilename(fname); } // so</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"> MyObject obj; // much</font></div><div><font class="Apple-style-span" face="'courier new', monospace">} // typing!</font></div><div><font class="Apple-style-span" face="'courier new', monospace"><br>
</font></div><div><font class="Apple-style-span" face="'courier new', monospace">// later ...</font></div><div><font class="Apple-style-span" face="'courier new', monospace">manager.create!(MyObjectWithFileName)("filename.txt"); // phew..! now repeat for every other overload</font></div>
</blockquote><div><font class="Apple-style-span" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">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).</font></div>
<div><font class="Apple-style-span" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">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...</font></div>
<div><div><div><div><br>-- <br>Atenciosamente / Sincerely,<br>Guilherme ("n2liquid") Vieira<br>
</div></div></div></div>