Tobias Weingartner wrote in message ...
>For 1-byte things, use the type "byte".
>Say what you mean, mean what you say.  wchar?  If you use UTF, it could
>be vchar (variable length), etc...


I frequently want to overload characters differently than bytes, so using "byte" for ascii doesn't work well for me.

In article <9lsc7e$1di3$2@digitaldaemon.com>, Walter wrote:
> 
> Tobias Weingartner wrote in message ...
> >For 1-byte things, use the type "byte".
> >Say what you mean, mean what you say.  wchar?  If you use UTF, it could
> >be vchar (variable length), etc...
> 
> 
> I frequently want to overload characters differently than bytes, so using "byte" for ascii doesn't work well for me.

That's exactly what I'm saying.  For charaters, use the character type. An array of these could be a string.  Could be that the base library (or the language if necessary) could define a string class as well (index entries are of type character).

What I'm saying is that wchar is a bad name.  They are not "wide" chars, but what you really want is a "character".  So name it as such.  A char can be anything, even variable length (UTF-8 for example).

If you need byte-sized quantities in your program, use "byte".  If you need a character (possibly byte, word, qword, or variable length), use character.

--Toby.

In article <9lih2u$10ca$2@digitaldaemon.com>, Walter says...
>
>
>Sheldon Simms wrote in message <9lgvsh$2jb7$1@digitaldaemon.com>...
>>Im Artikel <9levtq$10ji$1@digitaldaemon.com> schrieb "Walter" <walter@digitalmars.com>:
>>
>>> I've found I've wanted to support both ascii and unicode simultaneously in programs, hence I thought two different types was appropriate. I was constantly irritated by having to go through and either subtract or add L's in front of the strings. The macros to do it automatically are ugly. Hence, the idea that the string literals should be implicitly convertible to either char[] or wchar[].

Perhaps some consideration of an existing long-lived internationalized class library would be appropriate... [Cocoa]

Representing strings as objects allows you to use strings wherever you use other objects. It also provides the benefits of encapsulation, so that string objects can use whatever encoding and storage [single-byte, multi-byte, or unicode] is needed for efficiency while simply appearing as arrays of characters. The class-cluster's two public classes, NSString and NSMutableString, declare the programmatic interface for noneditable and editable strings, respectively.

Even though a string presents itself as an array of Unicode characters (Unicode is a registered trademark of Unicode, Inc.) its internal representation could be otherwise...

A class cluster is one public class, whose visible 'constructors' (aka 'factory methods') instantiate appropriate hidden subclasses. So UnicodeString subclass, JapaneseShiftJISString subclass, ChineseBigFiveString subclass, and AsciiString subclass are hidden, but their parent classes visible. [I made up those names. Since they are hidden, it doesn't matter how many subclasses of NSString and NSMutableString there are - they all conform to the same public interface.]

<http://developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/ObjC_classic/Classes/NSString.html#//apple_ref/occ/cl/NSString>

I believe the objective-C compiler translates @"some string" into an NSString (I'm not sure if the compiler supports unicode string constants yet.)

---
C. Keith Ray <http://homepage.mac.com/keithray/resume2.html> <http://homepage.mac.com/keithray/xpminifaq.html>

"c. keith ray" <c._member@pathlink.com> wrote in message news:aak0n0$14gi$1@digitaldaemon.com... <http://developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/ObjC_ classic/Classes/NSString.html#//apple_ref/occ/cl/NSString>

It's a great idea, but it appears to be copyrighted by Apple.

In article <aal1h7$23cc$1@digitaldaemon.com>,
 "Walter" <walter@digitalmars.com> wrote:

> "c. keith ray" <c._member@pathlink.com> wrote in message news:aak0n0$14gi$1@digitaldaemon.com... <http://developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/ObjC_ classic/Classes/NSString.html#//apple_ref/occ/cl/NSString>
> 
> It's a great idea, but it appears to be copyrighted by Apple.

See also: <http://www.gnustep.org/>

The objective-C version of Apple's Foundation library (which defines the String classes) is not open-source. The C version is open-source and has equivalent functionality.

Apple's open-source license is at: <http://www.opensource.apple.com/apsl/>

The c version of the Foundation library is at: <http://www.opensource.apple.com/projects/darwin/1.4/projects.html> look for "CoreFoundation  226-14.1  Core Foundation tool kit"
-- 
C. Keith Ray

<http://homepage.mac.com/keithray/xpminifaq.html>

Ok, Apple's open source license looks like it can be used. Do you want to take the lead in converting it to D?

"Keith Ray" <k1e2i3t4h5r6a7y@1m2a3c4.5c6o7m> wrote in message news:k1e2i3t4h5r6a7y-9BED6F.07530430042002@digitalmars.com...
> In article <aal1h7$23cc$1@digitaldaemon.com>,
>  "Walter" <walter@digitalmars.com> wrote:
>
> > "c. keith ray" <c._member@pathlink.com> wrote in message news:aak0n0$14gi$1@digitaldaemon.com...
> >
<http://developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/ObjC_
> > classic/Classes/NSString.html#//apple_ref/occ/cl/NSString>
> >
> > It's a great idea, but it appears to be copyrighted by Apple.
>
> See also: <http://www.gnustep.org/>
>
> The objective-C version of Apple's Foundation library (which defines the String classes) is not open-source. The C version is open-source and has equivalent functionality.
>
> Apple's open-source license is at: <http://www.opensource.apple.com/apsl/>
>
> The c version of the Foundation library is at: <http://www.opensource.apple.com/projects/darwin/1.4/projects.html> look for "CoreFoundation  226-14.1  Core Foundation tool kit"
> --
> C. Keith Ray
>
> <http://homepage.mac.com/keithray/xpminifaq.html>

In article <aamfkp$2p6o$1@digitaldaemon.com>,
 "Walter" <walter@digitalmars.com> wrote:

> Ok, Apple's open source license looks like it can be used. Do you want to take the lead in converting it to D?

... in my extensive free time? I wish I did have time for that...

I have the desire to implement an OO language very similar to Smalltalk [objects all the way down] but with syntax more like JavaScript or Java without type declarations, using techniques from Threaded Interpreted Languages (kinds like Forth or Postscript).

I do plan to look at D in more detail real soon now.

PS: I'm a Macintosh user by choice (I spend most of day-job time programming on Windows), so I can't use your D compiler yet.
-- 
C. Keith Ray

<http://homepage.mac.com/keithray/xpminifaq.html>

"Keith Ray" <k1e2i3t4h5r6a7y@1m2a3c4.5c6o7m> wrote in message news:k1e2i3t4h5r6a7y-35A6F7.20384830042002@digitalmars.com...
> PS: I'm a Macintosh user by choice (I spend most of day-job time programming on Windows), so I can't use your D compiler yet.

If you want, you can also do a Mac port starting with the gnu compiler sources for the Mac.