I tried something like:

   alias char [] string;

   int main(string [] args)
   {
       printf("%s\n",(char *)args[0]);
       return 0;
   }

hey, and it worked!

But only until I added

   import string;

   :-(

Ok, no problem. But the question is: Why do you live without getting rid of this "string is an char array" type of thinking. Although it is the case, there is no need to reflect this in all interfaces and the daily work.

E. g. the call
    char [][] files = DirFindFile('c:\dmd','*.d',DFF_FILES|DFF_RECURSIVE);
I just posted in a separate thread would look more beautiful
written as
    String [] files = DirFindFile('c:\dmd','*.d',DFF_FILES|DFF_RECURSIVE);
wouldn't it?

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Huhh, now this is going to be a long thread... :)

I think I completely agree with Helmut, and with Matthew W., and Mark E. and probably many others. And I let them talk -- they can do it better.

So the battle has begun... Good luck, folks! :)

Cheers,
Sab


"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3E8D5571.E6234E26@hls.via.at...
> I tried something like:
>
>    alias char [] string;
>
>    int main(string [] args)
>    {
>        printf("%s\n",(char *)args[0]);
>        return 0;
>    }
>
> hey, and it worked!
>
> But only until I added
>
>    import string;
>
>    :-(
>
> Ok, no problem. But the question is: Why do you live without getting rid of this "string is an char array" type of thinking. Although it is the case, there is no need to reflect this in all interfaces and the daily work.
>
> E. g. the call
>     char [][] files = DirFindFile('c:\dmd','*.d',DFF_FILES|DFF_RECURSIVE);
> I just posted in a separate thread would look more beautiful
> written as
>     String [] files = DirFindFile('c:\dmd','*.d',DFF_FILES|DFF_RECURSIVE);
> wouldn't it?
>
> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com

Hello,

I think that an array of chars was probably appropriate, but now that Unicode is
being considered for the language, I think a primitive string type might be
necessary, because an array of uneven sized chars would be very awkward when
talking about indexing (ie. is mystr[6] talking about the 6th byte, or the 6th
character?) and declaring new strings ("char [40] mystr;", is this 40 bytes, or
40 characters long?). Basically, stuff that has already been talked about in
here.
A dedicated string type might resolve some of this ambiguity by providing, for
example, both .length (characters) and .size properties (byte-size). Stuff that
is important for strings, but not really appropriate for other array types. I
don't really care too much either way, and if we are stuck with good old ASCII,
it really doesn't matter either way. But if Unicode is put in, then some
mechanism should be put in place to take care of these issues, whether its a
string type or not. And yes, this is probably going to be the start of a long,
painful thread. =)

-Jon

In article <3E8D5571.E6234E26@hls.via.at>, Helmut Leitner says...
>
>I tried something like:
>
>   alias char [] string;
> 
>   int main(string [] args)
>   {
>       printf("%s\n",(char *)args[0]);
>       return 0;
>   }
>
>hey, and it worked!
>
>But only until I added
>
>   import string;
>
>   :-(
>
>Ok, no problem. But the question is: Why do you live without getting rid of this "string is an char array" type of thinking. Although it is the case, there is no need to reflect this in all interfaces and the daily work.
>
>E. g. the call
>    char [][] files = DirFindFile('c:\dmd','*.d',DFF_FILES|DFF_RECURSIVE);
>I just posted in a separate thread would look more beautiful written as
>    String [] files = DirFindFile('c:\dmd','*.d',DFF_FILES|DFF_RECURSIVE);
>wouldn't it?
>
>-- 
>Helmut Leitner    leitner@hls.via.at
>Graz, Austria   www.hls-software.com

Not long; not painful. Simply agree



"Jonathan Andrew" <Jonathan_member@pathlink.com> wrote in message news:b6ktj0$2o0u$1@digitaldaemon.com...
> Hello,
>
> I think that an array of chars was probably appropriate, but now that
Unicode is
> being considered for the language, I think a primitive string type might
be
> necessary, because an array of uneven sized chars would be very awkward
when
> talking about indexing (ie. is mystr[6] talking about the 6th byte, or the
6th
> character?) and declaring new strings ("char [40] mystr;", is this 40
bytes, or
> 40 characters long?). Basically, stuff that has already been talked about
in
> here.
> A dedicated string type might resolve some of this ambiguity by providing,
for
> example, both .length (characters) and .size properties (byte-size). Stuff
that
> is important for strings, but not really appropriate for other array
types. I
> don't really care too much either way, and if we are stuck with good old
ASCII,
> it really doesn't matter either way. But if Unicode is put in, then some mechanism should be put in place to take care of these issues, whether its
a
> string type or not. And yes, this is probably going to be the start of a
long,
> painful thread. =)
>
> -Jon
>
> In article <3E8D5571.E6234E26@hls.via.at>, Helmut Leitner says...
> >
> >I tried something like:
> >
> >   alias char [] string;
> >
> >   int main(string [] args)
> >   {
> >       printf("%s\n",(char *)args[0]);
> >       return 0;
> >   }
> >
> >hey, and it worked!
> >
> >But only until I added
> >
> >   import string;
> >
> >   :-(
> >
> >Ok, no problem. But the question is: Why do you live without getting rid of this "string is an char array" type of thinking. Although it is the case, there is no need to reflect this in all interfaces and the daily work.
> >
> >E. g. the call
> >    char [][] files =
DirFindFile('c:\dmd','*.d',DFF_FILES|DFF_RECURSIVE);
> >I just posted in a separate thread would look more beautiful written as
> >    String [] files =
DirFindFile('c:\dmd','*.d',DFF_FILES|DFF_RECURSIVE);
> >wouldn't it?
> >
> >--
> >Helmut Leitner    leitner@hls.via.at
> >Graz, Austria   www.hls-software.com
>
>

Would it be appropriate to think of a String class within a template. You could declare your string to be a UTF-8 or UTF-16 or ECDEC or whatever simply by instantiating the String template.

I know that this isn't what templates are technically desinged to do, but it seems like a good idea to me.

--Benji

>I think that an array of chars was probably appropriate, but now that Unicode is being considered for the language, I think a primitive string type might be necessary, because an array of uneven sized chars would be very awkward when talking about indexing (ie. is mystr[6] talking about the 6th byte, or the 6th character?) and declaring new strings ("char [40] mystr;", is this 40 bytes, or 40 characters long?).

Sounds like quite a good idea to me.

Well, but first, it would be good to have that
generic string "something". ;)

Currently, calling an array of bytes a string
is like calling an Otto engine a car... (It's
not even a class inheritance thing.)

Cheers,
Lunar Sab


"Benji Smith" <Benji_member@pathlink.com> wrote in message news:b6l4vj$2t15$1@digitaldaemon.com...
> Would it be appropriate to think of a String class within a template. You
could
> declare your string to be a UTF-8 or UTF-16 or ECDEC or whatever simply by instantiating the String template.
>
> I know that this isn't what templates are technically desinged to do, but
it
> seems like a good idea to me.
>
> --Benji
>
> >I think that an array of chars was probably appropriate, but now that
Unicode is
> >being considered for the language, I think a primitive string type might
be
> >necessary, because an array of uneven sized chars would be very awkward
when
> >talking about indexing (ie. is mystr[6] talking about the 6th byte, or
the 6th
> >character?) and declaring new strings ("char [40] mystr;", is this 40
bytes, or
> >40 characters long?).
>
>

Howdy,

I think that the templated way of doing strings is probably adding more abstraction and complication to the string concept, which at this point should be a primitive type in the language, whether it is a completely new type or still an array of chars with special properties. That's just my opinion though, and I confess to being afraid of templates, coming mostly from a C/Java background.

-Jon

In article <b6l4vj$2t15$1@digitaldaemon.com>, Benji Smith says...
>
>Would it be appropriate to think of a String class within a template. You could declare your string to be a UTF-8 or UTF-16 or ECDEC or whatever simply by instantiating the String template.
>
>I know that this isn't what templates are technically desinged to do, but it seems like a good idea to me.
>
>--Benji
>
>>I think that an array of chars was probably appropriate, but now that Unicode is being considered for the language, I think a primitive string type might be necessary, because an array of uneven sized chars would be very awkward when talking about indexing (ie. is mystr[6] talking about the 6th byte, or the 6th character?) and declaring new strings ("char [40] mystr;", is this 40 bytes, or 40 characters long?).
>
>

Luna Kid wrote:
> Currently, calling an array of bytes a string
> is like calling an Otto engine a car... (It's
> not even a class inheritance thing.)

Sorry, I can't agree. In programming we deal with real world
objects and give them names (like File, String or System).
These names may be thought to represent virtual objects,
that may be handled
   - by handles (like MS windows HWND, file handles)
   - by names (like a customer in a database, file delete)
   - by OO object references
   - implicitly withou handle ( SystemRestart(); )
   - ...

I think that the OO feeling is wrong, that only a class is a good abstraction and that anything of importance must become a class. This feeling developed, because OO is overhyped to a point where this hype effectively reduces the quality of resulting code.

There can be no better API functions than
   FileDelete("test.txt");
   String []=UrlGetStringArray("http://walterbright.com");
because they express what the programmer wants to do in a
single "sentence" *and* do it. Notice that there is not a
single formal object involved.

So IMHO, whether something is a formal object or not, should be considered an implementation detail.

If Unicode strings are a topic (I do know little about them, I always thought we would just switch to 16-Bit-characters sometime in the future) then someone could create a class to wrap its complexities.

I would vote for "class Struni" and suggest that a team forms to prototype it to the point, where Walter can just take it and make it part of Phobos.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

For better or worse, UNICODE strings are no long as simple as "16-bit characters".  That's just one example of why this is a rather thorny issue.

   Dan

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3E8E9AAF.865E0DFF@hls.via.at...
>
>
> Luna Kid wrote:
> > Currently, calling an array of bytes a string
> > is like calling an Otto engine a car... (It's
> > not even a class inheritance thing.)
>
> Sorry, I can't agree. In programming we deal with real world
> objects and give them names (like File, String or System).
> These names may be thought to represent virtual objects,
> that may be handled
>    - by handles (like MS windows HWND, file handles)
>    - by names (like a customer in a database, file delete)
>    - by OO object references
>    - implicitly withou handle ( SystemRestart(); )
>    - ...
>
> I think that the OO feeling is wrong, that only a class is a good abstraction and that anything of importance must become a class. This feeling developed, because OO is overhyped to a point where this hype effectively reduces the quality of resulting code.
>
> There can be no better API functions than
>    FileDelete("test.txt");
>    String []=UrlGetStringArray("http://walterbright.com");
> because they express what the programmer wants to do in a
> single "sentence" *and* do it. Notice that there is not a
> single formal object involved.
>
> So IMHO, whether something is a formal object or not, should be considered an implementation detail.
>
> If Unicode strings are a topic (I do know little about them, I always thought we would just switch to 16-Bit-characters sometime in the future) then someone could create a class to wrap its complexities.
>
> I would vote for "class Struni" and suggest that a team forms to prototype it to the point, where Walter can just take it and make it part of Phobos.
>
> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com

"J. Daniel Smith" wrote:
> 
> For better or worse, UNICODE strings are no long as simple as "16-bit characters".  That's just one example of why this is a rather thorny issue.

I understand that, but the existance of certain encodings - e. g. in a web page - doesn't immediately mean to me that there is the need for a native type or a class handling these encodings (maybe to have transforming functions is enough).

I suppose that this comes from my lack of knowledge in this area.
I hadn't yet time to read the existing older threads about this topic.
Is there a summary of all the issues somewhere?

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com