On Thu, Feb 9, 2017 at 5:09 PM Ted F.A. van Gaalen <[email protected]> wrote:
> On 10 Feb 2017, at 00:11, Dave Abrahams <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
