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