U.Baumanis wrote:

>>If you want some Java-like string classes, I hacked some stuff together:
>>
>>That doesn't change the "readonly" (was: const) needs of the built-in
>>string types of D (code unit arrays) ? Just something of a workaround.
>>Kris has a much nicer wrapper (with ICU features) under the Mango Tree.
> 
> Thanks! It would be nice to have it in std.string.
> Well, better somewhere than nowhere. :-)

Don't misunderstand me, I do not think that D needs a String class...
(it was just a small example on how one could implement such a beast)

The default D string type is still "char[]".

Just wished there was a simple way to preserve the readonly-ness of it,
without resorting to using a fullblown wrapper class - like Java does ?

Something like: readonly char[] s = "hello";

--anders

PS. Name "const" has been renamed for political reasons.
    Kinda like typedef, which changed name into "alias".

In article <d7hl28$1ikj$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>U.Baumanis wrote:
>
>>>If you want some Java-like string classes, I hacked some stuff together:
>>>
>>>That doesn't change the "readonly" (was: const) needs of the built-in
>>>string types of D (code unit arrays) ? Just something of a workaround.
>>>Kris has a much nicer wrapper (with ICU features) under the Mango Tree.
>> 
>> Thanks! It would be nice to have it in std.string.
>> Well, better somewhere than nowhere. :-)
>
>Don't misunderstand me, I do not think that D needs a String class... (it was just a small example on how one could implement such a beast)
>
>The default D string type is still "char[]".
>
>Just wished there was a simple way to preserve the readonly-ness of it, without resorting to using a fullblown wrapper class - like Java does ?
>
>Something like: readonly char[] s = "hello";
>
>--anders
>
>PS. Name "const" has been renamed for political reasons.
>     Kinda like typedef, which changed name into "alias".

You are right! I forgot why i wanted a String class... May be because I have to use Java at work. ;-)

--
ubau

On Tue, 31 May 2005 00:46:35 -0700, Walter wrote:


[snip]

> A number of languages use the immutable string idiom, and its corollary "always implicitly copy the string when writing to it". They all share another common characteristic - they're slow, and they're slow in a manner that is *not fixable*. And they're not just slower by a factor, many algorithms run *exponentially* slower because of the copying.
> 
> D must be fast, and the only way to be fast with strings (and arrays) is to not have the language implicitly copy them, but to allow the programmer the flexibility to copy or not copy. To know when to copy, use the Copy On Write principle (COW). That is, if you're not *sure* you've got the only copy of a string, .dup it before modifying it.

I think there are two distinct aspects that are sometimes being confused or mingled. One is the idea that the compiler must *prevent* read-only variables from being modified, and the other is that the compiler must *report* when it detects (during compilation) code that attempts (i.e would attempt at run time) to write to a read-only item.

The first idea is the subject of the CoW proposition above; that D takes the position that the compiler is not responsible for this but that the coder is.

But I still think that we haven't heard Walter's final position on the second idea. So Walter, what if we could indicate which items we would like to be read-only and if the compiler detects code which is writing to them, it issues an error message? I know this would not cause these items to be read-only, but it may help prevent silly coding errors such as the other silly coding errors you've already added protection for in D.

-- 
Derek Parnell
Melbourne, Australia
31/05/2005 11:02:10 PM

"Derek Parnell" <derek@psych.ward> wrote in message news:djl0rio88ubd$.1v38dy1thwnze.dlg@40tude.net...
> On Tue, 31 May 2005 00:46:35 -0700, Walter wrote:
>
>
> [snip]
>
>> A number of languages use the immutable string idiom, and its corollary
>> "always implicitly copy the string when writing to it". They all share
>> another common characteristic - they're slow, and they're slow in a
>> manner
>> that is *not fixable*. And they're not just slower by a factor, many
>> algorithms run *exponentially* slower because of the copying.
>>
>> D must be fast, and the only way to be fast with strings (and arrays) is
>> to
>> not have the language implicitly copy them, but to allow the programmer
>> the
>> flexibility to copy or not copy. To know when to copy, use the Copy On
>> Write
>> principle (COW). That is, if you're not *sure* you've got the only copy
>> of a
>> string, .dup it before modifying it.
>
> I think there are two distinct aspects that are sometimes being confused
> or
> mingled. One is the idea that the compiler must *prevent* read-only
> variables from being modified, and the other is that the compiler must
> *report* when it detects (during compilation) code that attempts (i.e
> would
> attempt at run time) to write to a read-only item.
>
> The first idea is the subject of the CoW proposition above; that D takes the position that the compiler is not responsible for this but that the coder is.
>
> But I still think that we haven't heard Walter's final position on the
> second idea. So Walter, what if we could indicate which items we would
> like
> to be read-only and if the compiler detects code which is writing to them,
> it issues an error message? I know this would not cause these items to be
> read-only, but it may help prevent silly coding errors such as the other
> silly coding errors you've already added protection for in D.
>

Derek, this is exactly what const does in C++.
It does one more thing in fact. char[] and const char[] are
distinct types so you can do:

void foo( char[] s) { ... }
void foo( const char[] s)  { ... }

This also allows you to clear show your intentions and so on.






> -- 
> Derek Parnell
> Melbourne, Australia
> 31/05/2005 11:02:10 PM

"Anders F Björklund" <afb@algonet.se> wrote in message news:d7ha36$18df$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>
>> And what will be your advice then for:
>>
>> class Url {
>>   char[] _hostname;
>>   char[] hostname() { return _hostname; }
>> }
>>
>> _hostname should not be changeable nor intentionally
>> nor accidentally.
>> hostname access pattern is primarily read. But it could possibly be
>> passed in some third party functions.
>>
>> I am serious. I really want to know how to design it better.
>
> Magic Eight Ball says:
>                ___
>               /   \
>              /     \
>             /  ASK  \
>            /  AGAIN  \
>           /   LATER   \
>           \___________/
>
> My own prediction is that we argue about it for a few months more, and then Walter caves in and adds a "readonly" keyword to D... :-)
>
> For the time being, I think returning the string and asking others to be nice is better than using a Class or a struct ?
>
>> I am remebering old good days of C programming with these char[]s. Damned fast but not maintainable.
>
> That's where we are at now, I suppose.
>
> I've already run into some things regarding string literals. And that was even before any potential class library user...
>
> Copy on Write is currently just a Gentlemen's Agreement. And it needs the client using Url.hostname to play along.

Yep, Anders, seems like we are on the same track with you.

The thing is: I really don't know of a good style of library/component design in D.

If I am writing all code in one EXE by myself -
fine - I am genetleman with myself. Well... even with
myself... 'Today me' and 'yesterday me' frequently
different persons.

But! If I am desisginig library of common use....

I can imagine: documentation starts from:

"For gentlemen only...."

"Andrew Fedoniouk" <news@terrainformatica.com> wrote ...
>
> "Anders F Björklund" <afb@algonet.se> wrote in message news:d7ha36$18df$1@digitaldaemon.com...
> > Andrew Fedoniouk wrote:
> >
> >> And what will be your advice then for:
> >>
> >> class Url {
> >>   char[] _hostname;
> >>   char[] hostname() { return _hostname; }
> >> }
> >>
> >> _hostname should not be changeable nor intentionally
> >> nor accidentally.
> >> hostname access pattern is primarily read. But it could possibly be
> >> passed in some third party functions.
> >>
> >> I am serious. I really want to know how to design it better.
> >
> > Magic Eight Ball says:
> >                ___
> >               /   \
> >              /     \
> >             /  ASK  \
> >            /  AGAIN  \
> >           /   LATER   \
> >           \___________/
> >
> > My own prediction is that we argue about it for a few months more, and then Walter caves in and adds a "readonly" keyword to D... :-)
> >
> > For the time being, I think returning the string and asking others to be nice is better than using a Class or a struct ?
> >
> >> I am remebering old good days of C programming with these char[]s. Damned fast but not maintainable.
> >
> > That's where we are at now, I suppose.
> >
> > I've already run into some things regarding string literals. And that was even before any potential class library user...
> >
> > Copy on Write is currently just a Gentlemen's Agreement. And it needs the client using Url.hostname to play along.
>
> Yep, Anders, seems like we are on the same track with you.

Aye. There's a fair number of people who share this concern, and we all seem to be asking for the same thing. I think/hope it's a matter of time rather than legitimacy.


> The thing is: I really don't know of a good style of library/component design in D.

FWIW: I've been forced down the path of the Gentleman's agreement, with the expectation that 'readonly' will materialize in some form. It is possible to minimise the occurence of such things, but it doesn't always provide the most lightweight implementation (as you noted elsewhere).


> If I am writing all code in one EXE by myself -
> fine - I am genetleman with myself. Well... even with
> myself... 'Today me' and 'yesterday me' frequently
> different persons.
>
> But! If I am desisginig library of common use....
>
> I can imagine: documentation starts from:
>
> "For gentlemen only...."

Good one! Perhaps we should come up with a GLA: "Gentleman's License Agreement" :-)

In article <d7ic55$2df4$1@digitaldaemon.com>, Kris says...
>
>FWIW: I've been forced down the path of the Gentleman's agreement, with the expectation that 'readonly' will materialize in some form. It is possible to minimise the occurence of such things, but it doesn't always provide the most lightweight implementation (as you noted elsewhere).

FWIW, logical const behavior can *almost* be modeled decently using a sort of honor system as well:

# Object
# {
#     bit mutable = true;
#     ...
# }
#
# class C
# {
#     int read()
#     {
#         return 0;
#     }
#
#     void write( int val )
#     in
#     {
#         assert( mutable );
#     }
#     body
#     {
#
#     }
# }
#
# void read( C val )
# in
# {
#     val.mutable = false;
# }
# out
# {
#     // this can 'restore' to the wrong state
#     val.mutable = true;
# }
# body
# {
#
# }
#
# void write( C val )
# {
#
# }

The obvious problems with the above are that (1) it requires a lot of cooperation and (2) the read function has no easy way of storing whether C was mutable *before* the function was called, so it may 'restore' the wrong state (though this issue could be solved with thread local storage, as the expense of added complexity).


Sean

Sean Kelly wrote:
> In article <d7ic55$2df4$1@digitaldaemon.com>, Kris says...
> 
>>FWIW: I've been forced down the path of the Gentleman's agreement, with the
>>expectation that 'readonly' will materialize in some form. It is possible to
>>minimise the occurence of such things, but it doesn't always provide the
>>most lightweight implementation (as you noted elsewhere).
> 
> 
> FWIW, logical const behavior can *almost* be modeled decently using a sort of
> honor system as well:
> 
> # Object
> # {
> #     bit mutable = true;
> #     ...
> # }
> # # class C
> # {
> #     int read()
> #     {
> #         return 0;
> #     }
> # #     void write( int val )
> #     in
> #     {
> #         assert( mutable );
> #     }
> #     body
> #     {
> # #     }
> # }
> # # void read( C val )
> # in
> # {
> #     val.mutable = false;
> # }
> # out
> # {
> #     // this can 'restore' to the wrong state
> #     val.mutable = true;
> # }
> # body
> # {
> # # }
> # # void write( C val )
> # {
> # # }
> 
> The obvious problems with the above are that (1) it requires a lot of
> cooperation and (2) the read function has no easy way of storing whether C was
> mutable *before* the function was called, so it may 'restore' the wrong state
> (though this issue could be solved with thread local storage, as the expense of
> added complexity).
> 
> 
> Sean
> 
> 
Do you have any ideas on how this could work with basic data types and arrays?  With classes, is it possible for the compiler to generate accessors for all members automatically?  That would ease implementation details.  Perhaps a template could be created so that class code could look like
class C
{
	bit mutable;
	mixin constcapable!(int) someInt;
}

Brad

"Brad Beveridge" <brad@somewhere.net> wrote in message news:d7ifkp$2goj$1@digitaldaemon.com...
> Sean Kelly wrote:
>> In article <d7ic55$2df4$1@digitaldaemon.com>, Kris says...
>>
>>>FWIW: I've been forced down the path of the Gentleman's agreement, with
>>>the
>>>expectation that 'readonly' will materialize in some form. It is possible
>>>to
>>>minimise the occurence of such things, but it doesn't always provide the
>>>most lightweight implementation (as you noted elsewhere).
>>
>>
>> FWIW, logical const behavior can *almost* be modeled decently using a
>> sort of
>> honor system as well:
>>
>> # Object
>> # {
>> #     bit mutable = true;
>> #     ...
>> # }
>> # # class C
>> # {
>> #     int read()
>> #     {
>> #         return 0;
>> #     }
>> # #     void write( int val )
>> #     in
>> #     {
>> #         assert( mutable );
>> #     }
>> #     body
>> #     {
>> # #     }
>> # }
>> # # void read( C val )
>> # in
>> # {
>> #     val.mutable = false;
>> # }
>> # out
>> # {
>> #     // this can 'restore' to the wrong state
>> #     val.mutable = true;
>> # }
>> # body
>> # {
>> # # }
>> # # void write( C val )
>> # {
>> # # }
>>
>> The obvious problems with the above are that (1) it requires a lot of
>> cooperation and (2) the read function has no easy way of storing whether
>> C was
>> mutable *before* the function was called, so it may 'restore' the wrong
>> state
>> (though this issue could be solved with thread local storage, as the
>> expense of
>> added complexity).
>>
>>
>> Sean
>>
>>
> Do you have any ideas on how this could work with basic data types and
> arrays?  With classes, is it possible for the compiler to generate
> accessors for all members automatically?  That would ease implementation
> details.  Perhaps a template could be created so that class code could
> look like
> class C
> {
> bit mutable;
> mixin constcapable!(int) someInt;
> }
>
> Brad

The main problem that for basic types there are no solution in principle. At least I did not find proper idiom.

I've ended up with a "solution" to patch std.internals and to add readonly flag to arrays. But this is not working for pointers.

The only feasible solution is const - checks at compile time and not in runtime.

Andrew.

"Kris" <fu@bar.com> wrote in message news:d7ic55$2df4$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote ...
>>
>> "Anders F Björklund" <afb@algonet.se> wrote in message news:d7ha36$18df$1@digitaldaemon.com...
>> > Andrew Fedoniouk wrote:
>> >
>> >> And what will be your advice then for:
>> >>
>> >> class Url {
>> >>   char[] _hostname;
>> >>   char[] hostname() { return _hostname; }
>> >> }
>> >>
>> >> _hostname should not be changeable nor intentionally
>> >> nor accidentally.
>> >> hostname access pattern is primarily read. But it could possibly be
>> >> passed in some third party functions.
>> >>
>> >> I am serious. I really want to know how to design it better.
>> >
>> > Magic Eight Ball says:
>> >                ___
>> >               /   \
>> >              /     \
>> >             /  ASK  \
>> >            /  AGAIN  \
>> >           /   LATER   \
>> >           \___________/
>> >
>> > My own prediction is that we argue about it for a few months more, and then Walter caves in and adds a "readonly" keyword to D... :-)
>> >
>> > For the time being, I think returning the string and asking others to be nice is better than using a Class or a struct ?
>> >
>> >> I am remebering old good days of C programming with these char[]s. Damned fast but not maintainable.
>> >
>> > That's where we are at now, I suppose.
>> >
>> > I've already run into some things regarding string literals. And that was even before any potential class library user...
>> >
>> > Copy on Write is currently just a Gentlemen's Agreement. And it needs the client using Url.hostname to play along.
>>
>> Yep, Anders, seems like we are on the same track with you.
>
> Aye. There's a fair number of people who share this concern, and we all
> seem
> to be asking for the same thing. I think/hope it's a matter of time rather
> than legitimacy.
>
>
>> The thing is: I really don't know of a good style of library/component design in D.
>
> FWIW: I've been forced down the path of the Gentleman's agreement, with
> the
> expectation that 'readonly' will materialize in some form. It is possible
> to
> minimise the occurence of such things, but it doesn't always provide the
> most lightweight implementation (as you noted elsewhere).
>
>
>> If I am writing all code in one EXE by myself -
>> fine - I am genetleman with myself. Well... even with
>> myself... 'Today me' and 'yesterday me' frequently
>> different persons.
>>
>> But! If I am desisginig library of common use....
>>
>> I can imagine: documentation starts from:
>>
>> "For gentlemen only...."
>
> Good one! Perhaps we should come up with a GLA: "Gentleman's License Agreement" :-)

Cool! :)

My variation:

"Dgentleman's License Agreement"

Andrew.