<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Please see in-line response below<br class=""><div><blockquote type="cite" class=""><div class="">On 10 Feb 2017, at 03:56, Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="">shawnce@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Feb 9, 2017 at 5:09 PM Ted F.A. van Gaalen <<a href="mailto:tedvgiosdev@gmail.com" class="">tedvgiosdev@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 10 Feb 2017, at 00:11, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="gmail_msg" target="_blank">dabrahams@apple.com</a>> wrote:</div><br class="gmail_msg m_-8685886003293606080Apple-interchange-newline"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">on Thu Feb 09 2017, "Ted F.A. van Gaalen" <<a href="http://tedvgiosdev-at-gmail.com/" class="gmail_msg" target="_blank">tedvgiosdev-AT-gmail.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg">Hello Shawn<br class="gmail_msg">Just google with any programming language name and “string manipulation”<br class="gmail_msg">and you have enough reading for a week or so :o)<br class="gmail_msg">TedvG<br class="gmail_msg"></blockquote><br class="gmail_msg">That truly doesn't answer the question. It's not, “why do people index<br class="gmail_msg">strings with integers when that's the only tool they are given for<br class="gmail_msg">decomposing strings?” It's, “what do you have to do with strings that's<br class="gmail_msg">hard in Swift *because* you can't index them with integers?”<br class="gmail_msg"></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Hi Dave,</div><div class="gmail_msg">Ok. here are just a few examples: </div>Parsing and validating an ISBN code? or a (freight) container ID? or EAN13 perhaps? </div><div class="gmail_msg">of many of the typical combined article codes and product IDs that many factories and shops use? </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">or: </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">E.g. processing legacy files from IBM mainframes:</div><div class="gmail_msg">extract fields from ancient data records read from very old sequential files,</div><div class="gmail_msg">say, a product data record like this from a file from 1978 you’d have to unpack and process: </div><div class="gmail_msg">123534-09EVXD4568,991234,89ABCYELLOW12AGRAINESYTEMZ3453</div><div class="gmail_msg">into:</div><div class="gmail_msg">123, 534, -09, EVXD45, 68,99, 1234,99, ABC, YELLOW, 12A, GRAIN, ESYSTEM, Z3453.</div><div class="gmail_msg">product category, pcs, discount code, product code, price Yen, price $, class code, etc… </div><div class="gmail_msg">in Cobol and PL/1 records are nearly always defined with a fixed field layout like this.:</div><div class="gmail_msg">(storage was limited and very, very expensive, e.g. XML would be regarded as a </div><div class="gmail_msg">"scandalous waste" even the commas in CSV files! ) </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">01 MAILING-RECORD.</div><pre class="gmail_msg"><div class="gmail_msg"> 05 COMPANY-NAME PIC X(30).</div><div class="gmail_msg"> 05 CONTACTS.</div><div class="gmail_msg"> 10 PRESIDENT.</div><div class="gmail_msg"> 15 LAST-NAME PIC X(15).</div><div class="gmail_msg"> 15 FIRST-NAME PIC X(8).</div><div class="gmail_msg"> 10 VP-MARKETING.</div><div class="gmail_msg"> 15 LAST-NAME PIC X(15).</div><div class="gmail_msg"> 15 FIRST-NAME PIC X(8).</div><div class="gmail_msg"> 10 ALTERNATE-CONTACT.</div><div class="gmail_msg"> 15 TITLE PIC X(10).</div><div class="gmail_msg"> 15 LAST-NAME PIC X(15).</div><div class="gmail_msg"> 15 FIRST-NAME PIC X(8).</div><div class="gmail_msg"> 05 ADDRESS PIC X(15).</div><div class="gmail_msg"> 05 CITY PIC X(15).</div><div class="gmail_msg"> 05 STATE PIC XX.</div><div class="gmail_msg"> 05 ZIP PIC 9(5).</div><div class="gmail_msg"><div style="font-family:Avenir;white-space:normal" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">These are all character data fields here, except for the numeric ZIP field , however in Cobol it can be treated like character data. </div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"><div class="gmail_msg">So here I am, having to get the data of these old Cobol production files</div><div class="gmail_msg">into a brand new Swift based accounting system of 2017, what can I do? </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">How do I unpack these records and being the data into a Swift structure or class? </div><div class="gmail_msg">(In Cobol I don’t have to because of the predefined fixed format record layout).</div></div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">AFAIK there are no similar record structures with fixed fields like this available Swift?</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">So, the only way I can think of right now is to do it like this:</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">// mailingRecord is a Swift structure</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">struct MailingRecord</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">{</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"> var companyName: String = “no Name”</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"> var contacts: CompanyContacts</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"> .</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"> etc.. </div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">}</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">// recordStr was read here with ASCII encoding</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">// unpack data in to structure’s properties, in this case all are Strings</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">mailingRecord.companyName = recordStr[ 0..<30]</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">mailingRecord.contacts.president.lastName = recordStr[30..<45]</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">mailingRecord.contacts.president.firstName = recordStr[45..<53]</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">// and so on..</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">Ever worked for e.g. a bank with thousands of these files unchanged formats for years?</div><div style="font-family:Avenir;white-space:normal" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Avenir;white-space:normal" class="gmail_msg">Any alternative, convenient en simpler methods in Swift present? </div></div></pre></div></blockquote><div class="">These looks like examples of fix data format</div></div></div></div></blockquote><div>Hi Shawn,</div><div>No, it could also be an UTF-8 String.</div> <br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> that could be parsed from a byte buffer into strings, etc. </div></div></div></div></blockquote><div>How would you do that? could you please provide an example how to do this, with a byte buffer? </div><div>eg. read from flat ascii file —> unpack fields —> store in structure props? </div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">Likely little need to force them via a higher order string concept,</div></div></div></div></blockquote><div>What do you mean here with “high order string concept” ??</div><div>Swift is a high level language, I expect to do this with Strings directly,</div><div>instead of being forced to use low-level coding with byte arrays etc.</div><div>(I have/want no time for that)</div><div>Surely, one doesn’t have to resort to that in a high level language like Swift? </div><div>If I am certain that all characters in a file etc. are of fixed width, even in UTF-32</div><div>(in the above example I am 100% sure of that) then </div><div>using str[n1..<n2] is that case legitimate, because there are no</div><div>grapheme characters involved.</div><div>Therefore IMHO String direct subscripting should be available in Swift </div><div>for all Unicode types, and that the responsibility wether or not to use</div><div>this feature is with the programmer, not the language designer.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> at least not until unpacked from its compact byte form.</div></div></div></div></blockquote><div>I am sorry, but to me, it all sounds a bit like:</div><div>“why solve the problem with simple solution, when one can make it much</div><div>more complicated?” Be more pragmatic.</div></div><div><br class=""></div><div><br class=""></div><div>TedvG, <br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">-Shawn <br class=""></div></div></div>
</div></blockquote></div><br class=""></body></html>