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