www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - In Keyword and Associative Arrays

reply Sha Chancellor <Sha_member pathlink.com> writes:
I was just reading through the spec and noticed that delete foo["key"] deletes
the key and not the value.  
This seems very very very bad.  What if it's a sparse array?  delete arr[2] and
delete arr2[2] could do 
completely different things!  Seems to me there should be separate syntax for
deleting a key from an 
associative array.  

-Sha
May 27 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Sha Chancellor" <Sha_member pathlink.com> wrote in message
news:d77bsn$1n47$1 digitaldaemon.com...
 I was just reading through the spec and noticed that delete foo["key"] deletes
 the key and not the value.
 This seems very very very bad.  What if it's a sparse array?  delete arr[2] and
 delete arr2[2] could do
 completely different things!  Seems to me there should be separate syntax for
 deleting a key from an
 associative array.

 -Sha

Not sure eactly what you mean. Any chance you could give the address (or page name) of the documentation page that you were looking at, and a little more detail about what you mean, please? TZ
May 28 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message 
news:d79n43$l8l$1 digitaldaemon.com...
 "Sha Chancellor" <Sha_member pathlink.com> wrote in message 
 news:d77bsn$1n47$1 digitaldaemon.com...
 Not sure eactly what you mean.
 Any chance you could give the address (or page name) of the
 documentation page that you were looking at,
 and a little more detail about what you mean, please?

Say you have two arrays. One is an AA, one is a regular arry. A is a class: A[] arr1; A[int] arr2; Now, let's add some things: arr1.length=2; arr1[0]=new A; arr2[1]=new A; arr2[0]=new A; arr2[1]=new A; Now let's try deleting something: delete arr1[1]; delete arr2[1]; Now here's the thing: delete arr1[1] deletes the class instance held at that location. There is still an element at arr1[1]; it's just not a valid reference; But delete arr2[1] deletes the key-value pair in the AA. The class instance that was pointed to by that key still exists (though if there were no other references to it, it would be GCed). This is inconsistent and *gasp* context-sensitive grammar! Normally, arr2[1] returns the value of that key; but delete arr2[1] functions differently. The solution would be to have a .remove() property for AAs, such as: arr2.remove(1); Which would remove key 1 from the AA, while delete arr2[1]; Would delete the class ref pointed to by arr2[1]. The key would still exist. The problem, I think, comes with deprecating the delete syntax and bringing in the new; all the existing delete arr[i] would still be valid syntax, but would have a different effect. There would be no way for the compiler to say "hey, this syntax has been deprecated, change it to .remove()." Perhaps there would have to be a few transition versions where the delete syntax would be illegal altogether, to allow people to port their code to the new .remove() syntax, and then the delete could be brought back.
May 28 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:d7a545$v1g$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
 news:d79n43$l8l$1 digitaldaemon.com...
 "Sha Chancellor" <Sha_member pathlink.com> wrote in message
 news:d77bsn$1n47$1 digitaldaemon.com...
 Not sure eactly what you mean.
 Any chance you could give the address (or page name) of the
 documentation page that you were looking at,
 and a little more detail about what you mean, please?

Say you have two arrays. One is an AA, one is a regular arry. A is a class: A[] arr1; A[int] arr2; Now, let's add some things: arr1.length=2; arr1[0]=new A; arr2[1]=new A; arr2[0]=new A; arr2[1]=new A; Now let's try deleting something: delete arr1[1]; delete arr2[1]; Now here's the thing: delete arr1[1] deletes the class instance held at that location. There is still an element at arr1[1]; it's just not a valid reference; But delete arr2[1] deletes the key-value pair in the AA. The class instance that was pointed to by that key still exists (though if there were no other references to it, it would be GCed). This is inconsistent and *gasp* context-sensitive grammar! Normally, arr2[1] returns the value of that key; but delete arr2[1] functions differently. The solution would be to have a .remove() property for AAs, such as: arr2.remove(1); Which would remove key 1 from the AA, while delete arr2[1]; Would delete the class ref pointed to by arr2[1]. The key would still exist. The problem, I think, comes with deprecating the delete syntax and bringing in the new; all the existing delete arr[i] would still be valid syntax, but would have a different effect. There would be no way for the compiler to say "hey, this syntax has been deprecated, change it to .remove()." Perhaps there would have to be a few transition versions where the delete syntax would be illegal altogether, to allow people to port their code to the new .remove() syntax, and then the delete could be brought back.

Okay, so then the concern is over the fact that the delete function, when used on an element of an array, is intercepted and used to effect the array itself rather than that element, if and only if that array happens to be associative. Okay, that makes sense. Yes, I agree. A separate "remove" function would most likely have been better... but there is the issue of how a change could be safely introduced at this point. Having "delete" cause an error whenever used in accosiative arrays for some arbitrary number of DMD versions would have unpredictable results since there's no way to know how much (or which) source code would be updated and/or tested durring that time. This may be a case where some loss has to be accepted in order for progress to happen. DMD is afterall, still technically in beta testing of pre-1.0 versions, and the D specifications are still being evolved into a first release draft as I understand it. I personally have no problem with the current functionality, and would therefore guess that many other D programmers also have not ran into problems with the delete function working the way it currently does, but your argument makes sense, and I also recognize that a problem for any D programmer is in the long run a problem for the D language, and therefore a potential problem for all D programmers... So with that in mind, here's my recommendation... First, add a "remove" function for removal of a key and it's associated element from an associative array, to replace the current functionality of "delete" in that context. Let delete continue to work as it does in cases where no other meaning of "delete" would be possible, (for backward compatibility, and also because it makes sense in that context) and replace delete's current functionality in other cases with a functionality that is more consistant with how it works when used on an element of an ordinary array. Or, another possibility would be to deprecate the use of "delete" and replace it with "del" and "remove" for different current uses of delete... but I would not recommend this option since I see the other as a better choice. TZ
May 30 2005