I suggest

int K[char[] : loose]
and
int U[char[] : strict]

K["notpresentkey"]  would return  "" that is the init (but not create element)
and
U["notpresentkey"]  would rise an error

and also you could directly K["notyetpresentkey"]=12345; Instead of U.addKey("notyetpresentkey"); U["notyetpresentkey"]=12345;

So peaple can choose what way they want to use these AA-s.
This can be accomplished some other way, but the point is that both old (or old
like) behavior and new behavior should be present and could be choosed between.

Who is in favour please answer like Re: Subject: Who is in favour? - Myname I is against please answer like Re: Subject: Who is in favour? - NOT Myname

If you just want to reply, not vote : Re: Subject: Who is in favour?

My reasoning:
a)It is a very big change in a very late stage. It was many month ago that most
peaople assumed that we get 1.00 soon. I think it is bad if people have used to
this behaviour and now it is changed after that long time.

NB I think that D should be used in real life production because only there it can be really tested. For example some errors of D memory managment came out on my real web server with real load. They did not come in some testing environment. Walter fixed them quite fast then - thank you Walter.

When will D be ready, after version 0.999? I think it would be ok as long as versions 0.125 to 0.999 could be also used. I know that D is still developing and I can understand if I need to change my code a bit from time to time. But changeing some principial behavior after such long time without backward compatibility?

What is the message here? Yes D is a very good language, but wait - DONT USE IT!

In my mind we have 3 options
a)To go to 1.0 very fast, with a low quiality but atleast ready language.
b)To develop this thing for years and to tell people it's just a toy, don't use
it for serious development.
b)To continue do develop it but make it usefull for work. If you must make a big
change, make some kind of BACKWARD COMPATIBILITY.

Don't you want that D is used in real life too? Why do you think that D will be best born somewhere in the future when already other technologies have come and conquered the market.

If I decide that D is too young and start using other technologies for my work, wy do you think I will come back when some day you say that now it is ready?

And only in real life we can see if D really meets programmers needs. We should encourage it not discourage it.

b) I think that easy handling of AA-s should be possible. I am trying to win people over from PHP to D + fastCGI. They are used with easy AA-s. While I think that there is much easyness in PHP that is not good, I still think that easy AA-s are good. If they where so bad, you wouldn't tolerated it till version 0.127.

c) I use the old behaviour a lot. Maybe my program isn't quite usual one. Big part of it is my scripting language interpretator implementation. I use easy AA-s a lot there but I think they are quite usefull on other programs too, esp. web applications.

Thank You!

On Wed, 13 Jul 2005 20:47:12 +0000 (UTC), Martin <Martin_member@pathlink.com> wrote:

> I suggest
>
> int K[char[] : loose]
> and
> int U[char[] : strict]
>
> K["notpresentkey"]  would return  "" that is the init (but not create element)
> and
> U["notpresentkey"]  would rise an error
>
> and also you could directly K["notyetpresentkey"]=12345;
> Instead of U.addKey("notyetpresentkey");
> U["notyetpresentkey"]=12345;
>
> So peaple can choose what way they want to use these AA-s.
> This can be accomplished some other way, but the point is that both old (or old
> like) behavior and new behavior should be present and could be choosed between.
>
> Who is in favour please answer like Re: Subject: Who is in favour? - Myname
> I is against please answer like Re: Subject: Who is in favour? - NOT Myname
>
> If you just want to reply, not vote : Re: Subject: Who is in favour?
>
> My reasoning:
> a)It is a very big change in a very late stage. It was many month ago that most
> peaople assumed that we get 1.00 soon. I think it is bad if people have used to
> this behaviour and now it is changed after that long time.
>
> NB I think that D should be used in real life production because only there it
> can be really tested. For example some errors of D memory managment came out on
> my real web server with real load. They did not come in some testing
> environment. Walter fixed them quite fast then - thank you Walter.
>
> When will D be ready, after version 0.999? I think it would be ok as long as
> versions 0.125 to 0.999 could be also used. I know that D is still developing
> and I can understand if I need to change my code a bit from time to time. But
> changeing some principial behavior after such long time without backward
> compatibility?
>
> What is the message here? Yes D is a very good language, but wait - DONT USE IT!
>
> In my mind we have 3 options
> a)To go to 1.0 very fast, with a low quiality but atleast ready language.
> b)To develop this thing for years and to tell people it's just a toy, don't use
> it for serious development.
> b)To continue do develop it but make it usefull for work. If you must make a big
> change, make some kind of BACKWARD COMPATIBILITY.
>
> Don't you want that D is used in real life too? Why do you think that D will be
> best born somewhere in the future when already other technologies have come and
> conquered the market.
>
> If I decide that D is too young and start using other technologies for my work,
> wy do you think I will come back when some day you say that now it is ready?
>
> And only in real life we can see if D really meets programmers needs. We should
> encourage it not discourage it.
>
> b) I think that easy handling of AA-s should be possible. I am trying to win
> people over from PHP to D + fastCGI. They are used with easy AA-s. While I think
> that there is much easyness in PHP that is not good, I still think that easy
> AA-s are good. If they where so bad, you wouldn't tolerated it till version
> 0.127.
>
> c) I use the old behaviour a lot. Maybe my program isn't quite usual one. Big
> part of it is my scripting language interpretator implementation. I use easy
> AA-s a lot there but I think they are quite usefull on other programs too, esp.
> web applications.
>
> Thank You!
>
>

"Martin" <Martin_member@pathlink.com> wrote in message news:db3ukg$vka$1@digitaldaemon.com...
>I suggest
>
> int K[char[] : loose]
> and
> int U[char[] : strict]
>
> K["notpresentkey"]  would return  "" that is the init (but not create
> element)
> and
> U["notpresentkey"]  would rise an error

[snip]

> c) I use the old behaviour a lot. Maybe my program isn't quite usual one.
> Big
> part of it is my scripting language interpretator implementation. I use
> easy
> AA-s a lot there but I think they are quite usefull on other programs too,
> esp.
> web applications.

I'm confused that you say you use the old behavior, which inserts on failure, and differs from your loose proposal which would only return init. When you say you rely on the old behavior do you mean you rely on it not throwing?

Personally I wouldn't be against doing what Ruby does and allow a settable
default value. So an AA would get a property "default" that initially is
Value.init and is settable. It would be easy to implement in the current AA
code since a dummy bucket is already used to store the length and that value
of the dummy bucket can store the default. That would mean the author of the
Value type didn't have to magically guess what the default for all AA
applications should be. For example if a user wanted to have an AA where
null is a valid value then they can do something like
class Foo {}
int main() {
  Foo[int] x;
  x.default = new Foo; // unique indicator of
  x[1] = null;
  x[2] = new Foo;
  assert( x[3] is x.default ); // doesn't insert
  assert( x[1] !is x.default );
}

New syntax for behavior that can be addressed with methods?

In article <db3ukg$vka$1@digitaldaemon.com>, Martin says...
>
>I suggest
>
>int K[char[] : loose]
>and
>int U[char[] : strict]
>
>K["notpresentkey"]  would return  "" that is the init (but not create element)
>and
>U["notpresentkey"]  would rise an error
>
>and also you could directly K["notyetpresentkey"]=12345; Instead of U.addKey("notyetpresentkey"); U["notyetpresentkey"]=12345;
>
>So peaple can choose what way they want to use these AA-s.
>This can be accomplished some other way, but the point is that both old (or old
>like) behavior and new behavior should be present and could be choosed between.
>
>Who is in favour please answer like Re: Subject: Who is in favour? - Myname I is against please answer like Re: Subject: Who is in favour? - NOT Myname
>
>If you just want to reply, not vote : Re: Subject: Who is in favour?

Sounds like a lot of trouble to maintain backward compatibility to me.

I don't know if I prefer old "loose" method or the new "strict" way (if I understand the situation right), but I think it's better for Walter to choose his favorite than clutter up the language with more optional features. Any new complexity has to be evaluated for usefulness, and I think this proposal would make things too complicated.

jcc7

Oops used my middle name...	

In article <db47ji$171g$1@digitaldaemon.com>, J C Calvarese says...
>
>In article <db3ukg$vka$1@digitaldaemon.com>, Martin says...
>>
>>I suggest
>>
>>int K[char[] : loose]
>>and
>>int U[char[] : strict]
>>
>>K["notpresentkey"]  would return  "" that is the init (but not create element)
>>and
>>U["notpresentkey"]  would rise an error
>>
>>and also you could directly K["notyetpresentkey"]=12345; Instead of U.addKey("notyetpresentkey"); U["notyetpresentkey"]=12345;
>>
>>So peaple can choose what way they want to use these AA-s.
>>This can be accomplished some other way, but the point is that both old (or old
>>like) behavior and new behavior should be present and could be choosed between.
>>
>>Who is in favour please answer like Re: Subject: Who is in favour? - Myname I is against please answer like Re: Subject: Who is in favour? - NOT Myname
>>
>>If you just want to reply, not vote : Re: Subject: Who is in favour?
>
>Sounds like a lot of trouble to maintain backward compatibility to me.
>
>I don't know if I prefer old "loose" method or the new "strict" way (if I understand the situation right), but I think it's better for Walter to choose his favorite than clutter up the language with more optional features. Any new complexity has to be evaluated for usefulness, and I think this proposal would make things too complicated.
>
>jcc7

In article <opstvf0ve123k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Wed, 13 Jul 2005 20:47:12 +0000 (UTC), Martin <Martin_member@pathlink.com> wrote:
>
>> I suggest
>>
>> int K[char[] : loose]
>> and
>> int U[char[] : strict]
>>
>> K["notpresentkey"]  would return  "" that is the init (but not create
>> element)
>> and
>> U["notpresentkey"]  would rise an error
>>
>> and also you could directly K["notyetpresentkey"]=12345; Instead of U.addKey("notyetpresentkey"); U["notyetpresentkey"]=12345;
>>
>> So peaple can choose what way they want to use these AA-s.
>> This can be accomplished some other way, but the point is that both old
>> (or old
>> like) behavior and new behavior should be present and could be choosed
>> between.
>>
>> Who is in favour please answer like Re: Subject: Who is in favour? -
>> Myname
>> I is against please answer like Re: Subject: Who is in favour? - NOT
>> Myname
>>
>> If you just want to reply, not vote : Re: Subject: Who is in favour?
>>
>> My reasoning:
>> a)It is a very big change in a very late stage. It was many month ago
>> that most
>> peaople assumed that we get 1.00 soon. I think it is bad if people have
>> used to
>> this behaviour and now it is changed after that long time.
>>
>> NB I think that D should be used in real life production because only
>> there it
>> can be really tested. For example some errors of D memory managment came
>> out on
>> my real web server with real load. They did not come in some testing
>> environment. Walter fixed them quite fast then - thank you Walter.
>>
>> When will D be ready, after version 0.999? I think it would be ok as
>> long as
>> versions 0.125 to 0.999 could be also used. I know that D is still
>> developing
>> and I can understand if I need to change my code a bit from time to
>> time. But
>> changeing some principial behavior after such long time without backward
>> compatibility?
>>
>> What is the message here? Yes D is a very good language, but wait - DONT USE IT!
>>
>> In my mind we have 3 options
>> a)To go to 1.0 very fast, with a low quiality but atleast ready language.
>> b)To develop this thing for years and to tell people it's just a toy,
>> don't use
>> it for serious development.
>> b)To continue do develop it but make it usefull for work. If you must
>> make a big
>> change, make some kind of BACKWARD COMPATIBILITY.
>>
>> Don't you want that D is used in real life too? Why do you think that D
>> will be
>> best born somewhere in the future when already other technologies have
>> come and
>> conquered the market.
>>
>> If I decide that D is too young and start using other technologies for
>> my work,
>> wy do you think I will come back when some day you say that now it is
>> ready?
>>
>> And only in real life we can see if D really meets programmers needs. We
>> should
>> encourage it not discourage it.
>>
>> b) I think that easy handling of AA-s should be possible. I am trying to
>> win
>> people over from PHP to D + fastCGI. They are used with easy AA-s. While
>> I think
>> that there is much easyness in PHP that is not good, I still think that
>> easy
>> AA-s are good. If they where so bad, you wouldn't tolerated it till
>> version
>> 0.127.
>>
>> c) I use the old behaviour a lot. Maybe my program isn't quite usual
>> one. Big
>> part of it is my scripting language interpretator implementation. I use
>> easy
>> AA-s a lot there but I think they are quite usefull on other programs
>> too, esp.
>> web applications.
>>
>> Thank You!
>>
>>
>

Ben Hinkle wrote:
> "Martin" <Martin_member@pathlink.com> wrote in message news:db3ukg$vka$1@digitaldaemon.com...
>> ...
> Personally I wouldn't be against doing what Ruby does and allow a settable default value. So an AA would get a property "default" that initially is Value.init and is settable. It would be easy to implement in the current AA code since a dummy bucket is already used to store the length and that value of the dummy bucket can store the default. That would mean the author of the Value type didn't have to magically guess what the default for all AA applications should be. For example if a user wanted to have an AA where null is a valid value then they can do something like
> class Foo {}
> int main() {
>   Foo[int] x;
>   x.default = new Foo; // unique indicator of
>   x[1] = null;
>   x[2] = new Foo;
>   assert( x[3] is x.default ); // doesn't insert
>   assert( x[1] !is x.default );
> }  

That sounds pretty good to me.  In fact, that sounds like my preferred option.  (I can handle the others, but why should one be forced to.  But it's also reasonable to raise an exception if the default value isn't set.)