July 13, 2005
Martin Desperate wrote:
>>>Now throws an ArrayBoundsError if accessing an associative array with a key that is not already in the array. Previously, the key would be added to the array.
> 
> 
> All my work depends on previous behavior. My business logic is based on it.
> About 1 year of work, and this is not only hobby, but I was also hoping to get
> some commercial proffit from it.
> 
> Why should it throw an error? Take PHP, it does not give you an error on that
> occation. I have implemented a scripting language (in my project) and
> assosiative arrays have been much imporantce the way they where. 
> 
> In my mind the correct behaviour would be return the type default value if the
> element is not present (why waste memory in creating it) and not give an error.
> 
> Or if you like there could be a keyword like 'loose' (opposite of strict) and in
> that the AA-s would not throw an error but give type default value.
> 
> Certanly the old (or old like) behavior is VERY important.
> 
> By the way does someone have 0.0125 for me? I might be stuck with it for a very
> long time.
> 

no comments :)
ftp://ftp.digitalmars.com/dmd.125.zip

I hope this will helps
July 13, 2005
Hasan Aljudy wrote:

>> But it would still be quite frustrating this change, also because I think the
>> AA-s had some point as they where before. (Or better as I described: not
>> creating an element just returning default value.) 
>
> Maybe it's a little too late now, but for future reference: try writing a wrapper class around AA's, and use that class, and call its method.
> If D's implementation of AA changes, all you have to do is change few lines in your AA class.

Maybe we should do the same for strings too, then ? And arrays ? etc...
(i.e. add wrapper classes for the other D things that has problems too)

IMHO, More indirection is hardly the way to solve basic issues with the
D language, even if it is a nice way to abstract any advanced concepts.


If the arrays and tables are to be built-in to the language, then they
should be so smooth that you *don't* feel the need to do it yourself ?

Otherwise, it would be better off not burdering the language with those
concepts and implement them all in a library. Like in C++. Or in Java.

--anders
July 13, 2005
The problem here is that D is in beta phase, so things are almost guaranteed to change.

btw, in OOP we use wrappers for everything (hence the get() and set() methods all over the place).

Anders F Björklund wrote:
> Hasan Aljudy wrote:
> 
>>> But it would still be quite frustrating this change, also because I think the
>>> AA-s had some point as they where before. (Or better as I described: not
>>> creating an element just returning default value.) 
>>
>>
>> Maybe it's a little too late now, but for future reference: try writing a wrapper class around AA's, and use that class, and call its method.
>> If D's implementation of AA changes, all you have to do is change few lines in your AA class.
> 
> 
> Maybe we should do the same for strings too, then ? And arrays ? etc...
> (i.e. add wrapper classes for the other D things that has problems too)
> 
> IMHO, More indirection is hardly the way to solve basic issues with the
> D language, even if it is a nice way to abstract any advanced concepts.
> 
> 
> If the arrays and tables are to be built-in to the language, then they
> should be so smooth that you *don't* feel the need to do it yourself ?
> 
> Otherwise, it would be better off not burdering the language with those
> concepts and implement them all in a library. Like in C++. Or in Java.
> 
> --anders
July 13, 2005
Hasan Aljudy wrote:

> The problem here is that D is in beta phase, so things are almost guaranteed to change.

Since even the specification is changing, it's alpha stage (at most)

> btw, in OOP we use wrappers for everything (hence the get() and set() methods all over the place).

D makes quite a point of *not* needing wrappers for strings and arrays
and tables (AAs), very unlike how for instance C++ and Java does it... ?

Also, in D we have "properties" so there are no names "get" and "set";
As detailed on http://www.digitalmars.com/d/cpptod.html#properties

--anders
July 13, 2005
PHP throws a notice and generates an "Undefined index" or "Undefined offset" message if you try to read from an associative array where a key does not exist.  Many people ignore such errors, but they actually represent a significant speed/efficiency hit.

-[Unknown]


> Why should it throw an error? Take PHP, it does not give you an error on that
> occation. I have implemented a scripting language (in my project) and
> assosiative arrays have been much imporantce the way they where. 
July 14, 2005
Anders F Björklund wrote:
>> btw, in OOP we use wrappers for everything (hence the get() and set() methods all over the place).
> 
> 
> D makes quite a point of *not* needing wrappers for strings and arrays
> and tables (AAs), very unlike how for instance C++ and Java does it... ?
> 
> Also, in D we have "properties" so there are no names "get" and "set";
> As detailed on http://www.digitalmars.com/d/cpptod.html#properties
> 
> --anders

Yeah, I wasn't talking about D, just the OOP paradigm.

Also btw, properties are just sugar for get and set, I personally don't see much point to using them.
July 14, 2005
Hasan Aljudy wrote:

>> Also, in D we have "properties" so there are no names "get" and "set";
>> As detailed on http://www.digitalmars.com/d/cpptod.html#properties
[...]
> Also btw, properties are just sugar for get and set, I personally don't see much point to using them.

Actually I just meant the naming, as I'm normally using "overloading"
in C++ too - while I do use the JavaBeans standard (get/set) in Java.

I do think the "properties" are pretty sweet looking, though...

--anders
July 14, 2005
Actually it is not a bad idea.

struct STRING_CHAR
{
char []s[char []];
char []opIndex(char []a){
if(a not in s)return "";
else return s[a];
}
char [] opIndexAssign(char []what,char []a){
if(a not in s)s.addKey(a);
s[a]=what;
return what;
}
}

void test()
{   STRING_CHAR a;
STRING_CHAR b;
char []i;

i = a["yes"];   // same as i = a.opIndex(5,6,7);
a["yes"] = "no";                // same as a.opIndexAssign(7,i,3);
b["yes"]="yes";
b["yes"]=b["yes"]~"ok!";
printf(":%.*s %.*s \n",a["yes"],b["yes"]);
}

And could do templates so every type int [char[]], double [char[]] ... could be simply implemented.

Thank you!



In article <db1bev$1fvt$1@digitaldaemon.com>, Hasan Aljudy says...
>
>Martin Desperate wrote:
>> 
>> Ok, but what should I do? I don't like PHP at all, it very easy to write low
>> quality code in it but very hard to write high quality.
>> I did my last web application in C++ and it was no fun att all.
>> The best solution would be Java servkets and jsp, but I am no fan of Java and
>> Java is also much slower than D.
>> 
>> Using D 0.125 would be still better than to use other languages for know. (And
>> for future then it might be wise for me to write a code reconverter or
>> something.)
>> But it would still be quite frustrating this change, also because I think the
>> AA-s had some point as they where before. (Or better as I described: not
>> creating an element just returning default value.)
>
>Maybe it's a little too late now, but for future reference: try writing a wrapper class around AA's, and use that class, and call its method. If D's implementation of AA changes, all you have to do is change few lines in your AA class.


July 14, 2005
Yes you are right,this yould have given me an error also before.

In article <db1u3k$1um4$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"M" <M_member@pathlink.com> wrote in message news:db1cpm$1h6e$1@digitaldaemon.com...
>> Thank you.
>>
>> I think I should do some kind of grepping, but it won't be easy because I
>> have
>> quite complex issues like M[K["n_"~getqt(s)]~"_standard"][5] (where both M
>> and K
>> are AA-s) and so on.
>
>out of curiosity, what is the type of M? If the value type is a dynamic array then the [5] would end up throwing an ArrayIndexException if "_standard" wasn't in the map since inserting "_standard" would have set the value to be an empty array. If the value type was a static array then the [5] would work but my assumption is that "_standard" shouldn't be a key M.
>
>


July 28, 2005
Martin Desperate wrote:
>>>Now throws an ArrayBoundsError if accessing an associative array with a key that is not already in the array. Previously, the key would be added to the array.
> 
> 
> All my work depends on previous behavior. My business logic is based on it.
> About 1 year of work, and this is not only hobby, but I was also hoping to get
> some commercial proffit from it.
> 
> Why should it throw an error? Take PHP, it does not give you an error on that
> occation. I have implemented a scripting language (in my project) and
> assosiative arrays have been much imporantce the way they where. 
> 
> In my mind the correct behaviour would be return the type default value if the
> element is not present (why waste memory in creating it) and not give an error.
> 
> Or if you like there could be a keyword like 'loose' (opposite of strict) and in
> that the AA-s would not throw an error but give type default value.
> 
> Certanly the old (or old like) behavior is VERY important.
> 
> By the way does someone have 0.0125 for me? I might be stuck with it for a very
> long time.
> 
> 
How did you find all the occurrences on your code?

Antonio Monteiro
1 2
Next ›   Last »