Re: Eu vs perl
Kat wrote:
> Irv Mullins wrote
>Subject: Re: Eu vs perl
>
>> Everett Williams wrote:
>>
>> > Well let's see. If I am dealing with ASCII text characters, any value
>greater
>> > than 255 would be a start. If I am dealing with double byte characters,
>any
>> > value that won't fit into a double byte. The standards are published and
>> > clear. What can I add to them?
>>
>> How about a real-world example of where this has caused a problem?
>
>Actually, there is an example in the archives somewhere, or in the docs,
>where hour was defined as a range of 0-24 ( 0 to 24 hours in a day ), and if
>one attempted to hour = 25 , Eu faulted on not correct type or out of range.
>But i don't remember atm where this was. So Everett, maybe you could use
>this as string *typing*, but what i was after was more *functionality* in
>string manipulation, like the working code examples i gave. I don't know how
>you'd skip the ascii lowercase letters up to the ascii uppercase letters
>this way either, i haven't tried it, maybe if you described UppercaseChars
>and LowercaseChars, then joined them in the type definition, maybe?
>
>Kat,
>not so minimalist, but simplist(?).
The example you cite is in the online manual for 2.1 I really hate to use
ANYTHING that MS has as an example, but here we go. The whole code
page thing in MS triggers a cascading group of effects on strings,
alphabetizing, sorts in general, upper/lower case and so on. The subject
is complex, but really necessary unless you are going to limit yourself to
standard english. The issues still exist in standard english, but don't cause
the variations in code for handling. It is possible to limit a language to
english and survive in this Anglicized commercial world, but it isn't
necessarily desireable.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
