On Thu, 30 Dec 2010 17:10:00 +0100
"Jérôme M. Berger" <[email protected]> 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.
> > 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.
> > 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 ;-)
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
