Re: Textedit and txt

[brbarkstrom@gmail.com]

> ...
> 
> > Sorry to go back in the thread.  However, instead of creating a new
> > symbol '+' to indicate append,
> 
> Sorry, but "+" here is for conversion to or from type String. It has nothing 
> to do with "append".
> 
> The problem is that the conversion routine is named To_Bounded_String, which 
> is way too long to use in/with complex expressions. And the other way is 
> To_String, which is only a bit better. Especially if you are "use-adverse".
> 
> The existing "&" work in some cases, but not others (for instance, the call 
> to Put in the OPs example). Moreover, they're the reason that the package 
> has to be junked, because we cannot have proper string literals and the like 
> with them around (that would make everything ambiguous). Avoiding those 
> mixed things makes the packages a lot more sane (but then a conversion 
> operator is required).
> 
>                                       Randy.
> 
> 
> 
> 
> it might be easier to consult the Ada
> > RM.  In section A.4.4 of the Ada 2012 RM, there are a number of overloaded
> > functions specifically called 'Append'.  Furthermore, the second page of 
> > this
> > section specifically uses '&' as an append operator.  Since these two
> > constructions are already part of the package `Bounded_String', it isn't 
> > clear
> > what we gain by using a variant construction.
> >
> > Bruce B.

"Strings" are complicated.  Sedgewick and Wayne's book on "Algorithms, 
Fourth Edition" devotes about 150 pages to the subject.  Unfortunately,
the book is written in Java and the algorithm descriptions use Java
code.  The authors note that there are at least two abstract data types
that programmers can use to represent strings and warn about "wide API's"
that include so many objects and methods that they're impractical.  Thus
(and perhaps oddly), I agree with Dimity's comments.  I don't agree with
the notion of creating a "deprecated" category of items.  Why copy Java?

Bruce B.