Re: [boost] Re: new initialization lib, any interest?

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2002-11-20 07:10:43

----- Original Message -----
From: "Rob Stewart" <stewart_at_[hidden]>

> From: Thorsten Ottosen <nesotto_at_[hidden]>
> > From: "Yitzhak Sapir" <yitzhaks_at_[hidden]>
> > > On Wed, 9 Oct 2002, Thorsten Ottosen wrote:
> > >
> > > > The problem of missing a value in the assignment to
> > > > the map is hypothetical. If I wan't to map int to int, I can make
the
>
> No, it isn't hypothetical.  It is a reasonable situation to map
> from one numeric type to another, and to use integers for the
> initial values even when assigning to a floating point type.

It was hypothetical that the missing value should be a problem, not that
maps from 'int' to 'int' are.
If you fordot a value, an assertion will be triggered.

>
> > > > mapping just as clear by using newline or tabs:
> > > >
> > > > set_map( m ) += 1,2    2,3    3,4    5,6;
> > > > set_map( m ) += 1,2
> > > >                            2,3
> > > >                           3,4;
>
> As you can see, tabs can be a problem.  At least in mailing
> lists! ;-)
>
> > > Given that you yourself did not do well in giving an example of
> > > separation with whitespace, I think this speaks strongly for a
pair-wise
> > > syntax.
>
> I agree.
[snip]
  Your point, if I understand you
> correctly, is that the compiler would have complained had you
> been able to actually attempt to compile the above with a more
> compliant compiler.

no, if I had compiled it at all. No compiler accepts white spaces in
identifiers.

>
> > > The parenthesis form is not that hard.  Add a space between the values
and
> > > the parenthesis, and the value isn't buried:
> > >
> > > init(m)( 1, 2 )( 2, 3 )( 3, 4 );
>
> I don't put spaces within parenthetical expressions, so I'm
> accustomed to code like this:
>
>    init(m)(1, 2)(2, 3)(3, 4);
>
> I find that perfectly readable.

You could then also quickly be accustomed to code like m+= 1,2,  3,4; I
don't think
we're discussing anything that has to do with ambiguity, simple people's
personal preferences
for a certain syntax.  I think I mentioned in a mail that one could choose
to support
both syntaxes, but I'm not sure that is a good idea.

> > > In this case white space does enhance readability, but the syntax
> > > guarantees the user won't make a mistake.
>
> I find the spaces distracting, but since they are not required,
> but merely possible should your own sense of taste dictate them,
> I have no problem either way.

good. :-)

> > neither will he in the other case. ¨The concern is hypothetical and the
> > interface for map and eg vector will be different which is much worse
than
> > having both operator= and operator+=.
>
> The concern is not hypothetical.  If you have a
> std::map<int, double>, you could easily initialize it with only
> "pairs" of integers, and the compiler will be happy to convert
> integers to doubles for you.  How can you find an error if the
> compiler doesn't flag it?  How will you learn that you transposed
> a 2 and a 3 in such a case?  It depends upon how that
> transposition affects the rest of your code.  It may be invisible
> in most circumstances.
My imagination is just not good enough, please show an example with both
syntaxes and pinpoint
where the error appears.

> Couldn't you use map-like notation:
>
>    init(m)["ssdsd"] = Class(2, Cow(3)), ["dfedfe"] = Class(2, Cow(3));
>
> The idea is that init(m) would create an object that provides the
> subscript operator which takes the map's key type as a parameter
> and returns an object with an assignment operator which takes the
> map's value type as a parameter.  The assignment operator
> would return the original "init" object.  The "init" class
> provides the comma operator to allow chaining as shown.
>
> (Add whitespace to taste:
>
>    init(m)
>       ["ssdsd"]  = Class(2, Cow(3)),
>       ["dfedfe"] = Class(2, Cow(3));
> )
>
> What could be more intuitive?
init(m)
   ["sdsds"] -> Class( 2, Cow(3));

>(Efficiency may be another matter,
> but it's intuitive, right?)

yes. might not be such a bad idea.

>
> > >In your case, whitespace might
> > > add something, but the user can still make a mistake.  Even something
> > > like:
> > >
> > > set_map(m) += 1,2,   2,3,   3,4,   5,6,   7,8,  | 9,
> > >               9,10,  11,12, 13,14, 15,16  17,18
> > >               19,20;
> > >
> > > With the user screen margin occuring where the | passes is possible.
In
> > > this case, white space doesn't save him from this mistake.  And it
could
> > > be hard to find.
> >
> > no. as I said earlier, a missing value  will be caught at "bug-time"
(~the
> > first time the user runs the code).
>
> You're assuming the code path containing that initialization code
> will always run.  What if the situation leading to that code path
> wasn't tested?  That may not bode well for the testing
> methodology, but the point is that a compile time error is
> better.
I cannot imagine a situation where constant data in a program has not been
tested. I agree compile errors are better, but if it means you
ruin the interface, it might not be worth it.

regards
Thorsten