From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f868292008c639ce X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: C vs. Ada - strings Date: 2000/05/18 Message-ID: #1/1 X-Deja-AN: 625033959 Sender: bobduff@world.std.com (Robert A Duff) References: <390F0D93.F835FAD9@ftw.rsc.raytheon.com> <8en5o9$ihe$1@nnrp1.deja.com> <8eonos$e70$1@wanadoo.fr> <1fIU4.4668$Rx3.250161@typhoon.nyroc.rr.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 2000-05-18T00:00:00+00:00 List-Id: dale writes: > Pete wrote: > if you write > > Positive'Image("5"). You get back > > " 5", with a space for an optional - sign, even though it is a positive > > number! or even worse, > > (should read Positive'Imge (5)) > i've always thought of attributes such as these as rather low level > features good for debugging, but not really of much use for fancy > formatting. Still it can be annoying. You have to apply the trim > function, or slice the array yourself, which is annoying. The annoying extra blank is certainly a mistake. So is the verbose syntax. Why can't you say X'Image instead of Integer'Image(X)? After all, you can say "X + 1" (as opposed to something like Integer'Add(X, 1)). It's not necessary or helpful to mention the type every time you want to do something to an object or value. > instantiate a generic package to handle printing > > of > > numbers, instead of > > System.out.println("This is junk " + i); (where i is a numeric type). > > Yes, but with this simplicity you get a very real problem - the > inability to define new distinct numeric types. I don't agree. It's quite easy to design a language in which it is possible to define convenient output procedures, and still have multiple user-defined integer types. And I don't mean by making all the output primitives built-in, either (as in Pascal) -- I/O should be done in library packages, not as built-in primitives. >... Which do you think > is the bigger problem - having to choose b/w int and long for almost > all integer work (without the ability to have unsigned ints), > or having to instantiate (or do a type conversion) to get output? The former. But I think it's possible to get the best of both worlds, so I think it's a legitimate complaint to say that Text_IO is a pain in the neck compared to Java's primitives. On the other hand, Java has its own problems with strings. Eg, the fact that the equality comparison is pointer comparison. And "+" is a poor choice for the concatenation operator. > Note that you could always include your own package of functions > to get exactly the same behaviour as you see above in Java. I don't see how. Not if you have lots of user-defined integer types -- you have to declare something extra for every integer type, which does not match the convenience of the Java routines. - Bob