[swift-evolution] Strings in Swift 4

[Shawn Erickson]

On Thu, Feb 9, 2017 at 5:09 PM Ted F.A. van Gaalen <tedvgiosdev at gmail.com>
wrote:

> On 10 Feb 2017, at 00:11, Dave Abrahams <dabrahams at apple.com> wrote:
>
>
> on Thu Feb 09 2017, "Ted F.A. van Gaalen" <tedvgiosdev-AT-gmail.com>
> wrote:
>
> Hello Shawn
> Just google with any programming language name and “string manipulation”
> and you have enough reading for a week or so :o)
> TedvG
>
>
> That truly doesn't answer the question.  It's not, “why do people index
> strings with integers when that's the only tool they are given for
> decomposing strings?”  It's, “what do you have to do with strings that's
> hard in Swift *because* you can't index them with integers?”
>
>
> Hi Dave,
> Ok. here are just a few examples:
> Parsing and validating an ISBN code? or a (freight) container ID? or EAN13
> perhaps?
> of many of the typical combined article codes and product IDs that many
> factories and shops use?
>
> or:
>
> E.g. processing legacy files from IBM mainframes:
> extract fields from ancient data records read from very old sequential
> files,
> say, a product data record like this from a file from 1978 you’d have to
> unpack and process:
> 123534-09EVXD4568,991234,89ABCYELLOW12AGRAINESYTEMZ3453
> into:
> 123, 534, -09, EVXD45, 68,99, 1234,99, ABC, YELLOW, 12A, GRAIN, ESYSTEM,
> Z3453.
> product category, pcs, discount code, product code, price Yen, price $,
> class code, etc…
> in Cobol and PL/1 records are nearly always defined with a fixed field
> layout like this.:
> (storage was limited and very, very expensive, e.g. XML would be regarded
> as a
> "scandalous waste" even the commas in CSV files! )
>
> 01  MAILING-RECORD.
>
>        05  COMPANY-NAME            PIC X(30).
>        05  CONTACTS.
>            10  PRESIDENT.
>                15  LAST-NAME       PIC X(15).
>                15  FIRST-NAME      PIC X(8).
>            10  VP-MARKETING.
>                15  LAST-NAME       PIC X(15).
>                15  FIRST-NAME      PIC X(8).
>            10  ALTERNATE-CONTACT.
>                15  TITLE           PIC X(10).
>                15  LAST-NAME       PIC X(15).
>                15  FIRST-NAME      PIC X(8).
>        05  ADDRESS                 PIC X(15).
>        05  CITY                    PIC X(15).
>        05  STATE                   PIC XX.
>        05  ZIP                     PIC 9(5).
>
> These are all character data fields here, except for the numeric ZIP field , however in Cobol it can be treated like character data.
> So here I am, having to get the data of these old Cobol production files
> into a brand new Swift based accounting system of 2017, what can I do?
>
> How do I unpack these records and being the data into a Swift structure or class?
> (In Cobol I don’t have to because of the predefined fixed format record layout).
>
> AFAIK there are no similar record structures with fixed fields like this available Swift?
>
> So, the only way I can think of right now is to do it like this:
>
> // mailingRecord is a Swift structure
> struct MailingRecord
> {
>     var  companyName: String = “no Name”
>      var contacts: CompanyContacts
>      .
>      etc..
> }
>
> // recordStr was read here with ASCII encoding
>
> // unpack data in to structure’s properties, in this case all are Strings
> mailingRecord.companyName                       = recordStr[ 0..<30]
> mailingRecord.contacts.president.lastName  = recordStr[30..<45]
> mailingRecord.contacts.president.firstName = recordStr[45..<53]
>
>
> // and so on..
>
> Ever worked for e.g. a bank with thousands of these files unchanged formats for years?
>
> Any alternative, convenient en simpler methods in Swift present?
>
> These looks like examples of fix data format that could be parsed from a
byte buffer into strings, etc. Likely little need to force them via a
higher order string concept, at least not until unpacked from its compact
byte form.

-Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170210/4cb1a14d/attachment.html>