Re: [boost] Re: new initialization lib, any interest?
- Original Message - From: "Rob Stewart" <[EMAIL PROTECTED]> > From: Thorsten Ottosen <[EMAIL PROTECTED]> > > From: "Yitzhak Sapir" <[EMAIL PROTECTED]> > > > 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,22,33,45,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, 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 int
Re: [boost] Re: new initialization lib, any interest?
From: Thorsten Ottosen <[EMAIL PROTECTED]>
> From: "Yitzhak Sapir" <[EMAIL PROTECTED]>
> > 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.
> > > mapping just as clear by using newline or tabs:
> > >
> > > set_map( m ) += 1,22,33,45,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.
> maybe you didn't see my other reply? It was late :-) If I had tried to
> compile it I would have gotten one
> of your favorable compile-time errors. So to use your words, I don' t think
> it "speaks strongly" for anything.
> In fact, I would appreciate you'd not come up with false and irrelevant
> arguments.
They are neither false nor irrelevant arguments. He was,
however, exercising hyperbole. 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.
> > In any case, I'm against something like assign_map(m) += or
> > append_map(m) =. Does the first do a clear() before it assigns? Does the
> > second? The "set_map" or "append_map" or "assign_map" suggests one way,
> > the "+=" or "=" suggests another. This ambiguity does not occur with the
> > parenthesis form, as there is no way to specify "multiple" meanings. This
> > double meaning problem is also what led me to propose doing away with the
> > name altogether and having: m += 1,2, 2,3, 3,4, 5,6;
You make a great point.
> > 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.
> > 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.
> 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, 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.
> Spaces are always nice (I would always add spaces inside paranthesis as you
> did before), but the less parenthesis
> the better. The are still more desturbing than a comma. It might not be
> simple integers that are added:
>
> init( m)( "ssdsd", Class( 2, Cow( 3 ) ) )
>
> m += "dfedfe", Class( 2, Cow( 3 ) )
>
> the less parenthesis the better.
I find these readable:
init(m)("ssdsd", Class(2, Cow(3)));
m+= ("dfedfe", Class(2, Cow(3)));
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? (Efficiency may be another matter,
but it's intuitive, right?)
> >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 t
