www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Who is in favour?

reply Martin <Martin_member pathlink.com> writes:
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!
Jul 13 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
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!
Jul 13 2005
parent AJG <AJG_member pathlink.com> writes:
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!
Jul 13 2005
prev sibling next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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 );
}
Jul 13 2005
parent Charles Hixson <charleshixsn earthlink.net> writes:
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.)
Jul 19 2005
prev sibling next sibling parent reply David Medlock <noone nowhere.com> writes:
New syntax for behavior that can be addressed with methods?
Jul 13 2005
parent David Medlock <noone nowhere.com> writes:
Oops used my middle name...
Jul 13 2005
prev sibling parent reply J C Calvarese<technocrat7 gmail.com> writes:
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
Jul 13 2005
parent sai <sai_member pathlink.com> writes:
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
Jul 13 2005