> 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?
Kind Regards
TedvG
( example of the above Cobol record borrowed from here:
http://www.3480-3590-data-conversion.com/article-reading-cobol-layouts-1.html
<http://www.3480-3590-data-conversion.com/article-reading-cobol-layouts-1.html>
)
>
>>> On 9 Feb 2017, at 16:48, Shawn Erickson <[email protected]> wrote:
>>>
>>> I also wonder what folks are actually doing that require indexing
>>> into strings. I would love to see some real world examples of what
>>> and why indexing into a string is needed. Who is the end consumer of
>>> that string, etc.
>>>
>>> Do folks have so examples?
>>>
>>> -Shawn
>>>
>>> On Thu, Feb 9, 2017 at 6:56 AM Ted F.A. van Gaalen via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> Hello Hooman
>>> That invalidates my assumptions, thanks for evaluating
>>> it's more complex than I thought.
>>> Kind Regards
>>> Ted
>>>
>>>> On 8 Feb 2017, at 00:07, Hooman Mehr <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>>
>>>>> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution
>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>
>>>>> I now assume that:
>>>>> 1. -= a “plain” Unicode character (codepoint?) can result in one
>>>>> glyph.=-
>>>>
>>>> What do you mean by “plain”? Characters in some Unicode scripts are
>>>> by no means “plain”. They can affect (and be affected by) the
>>>> characters around them, they can cause glyphs around them to
>>>> rearrange or combine (like ligatures) or their visual
>>>> representation (glyph) may float in the same space as an adjacent
>>>> glyph (and seem to be part of the “host” glyph), etc. So, the
>>>> general relationship of a character and its corresponding glyph (if
>>>> there is one) is complex and depends on context and surroundings
>>>> characters.
>>>>
>>>>> 2. -= a grapheme cluster always results in just a single glyph,
>>>>> true? =-
>>>>
>>>> False
>>>>
>>>>> 3. The only thing that I can see on screen or print are glyphs
>>>>> (“carvings”,visual elements that stand on their own )
>>>>
>>>> The visible effect might not be a visual shape. It may be for example, the
>>>> way the surrounding shapes change or re-arrange.
>>>>
>>>>> 4. In this context, a glyph is a humanly recognisable visual form of
>>>>> a character,
>>>>
>>>> Not in a straightforward one to one fashion, not even in Latin / Roman
>>>> script.
>>>>
>>>>> 5. On this level (the glyph, what I can see as a user) it is not
>>>>> relevant and also not detectable
>>>>> with how many Unicode scalars (codepoints ?), grapheme, or even
>>>>> on what kind
>>>>> of encoding the glyph was based upon.
>>>>
>>>> False
>>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>
> --
> -Dave
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
